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This international preliminary examination report has been prepared by this International Preliminary Examining Authority 
and is transmitted to the applicant according to Article 36. 



This REPORT consists of a total of . 



. sheets, including this cover sheet. 



This report is also accompanied by ANNEXES, i.e., sheets of the description, claims and/or drawings which have been 
amended and are the basis for this report and/or sheets containing rectifications made before this Authority (see Rule 
70.16 and Section 607 of the Administrative Instructions under the PCT). 



These annexes consist of a total of _ 



sheets. 



This report contains indications relating to the following items: 
Basis of the report 
Priority 

Non-establishment of opinion with regard to novelty, inventive step and industrial applicability 
Lack of unity of invention 

Reasoned statement under Article 35(2) with regard to novelty, inventive step or industrial applicability; 
citations and explanations supporting such statement 

Certain documents cited 
Certain defects in the international application 
Certain observations on the international application 



I 


I2SI 


II 


□ 


III 


□ 


IV 


□ 


V 




VI 


□ 


VII 


□ 


VIII 


□ 



Date of submission of the demand 

09 October 2000 (09.10.00) 


Date of completion of this report 

08 June 2001 (08.06.2001) 


Name and mailing address of the IPEA/EP 
Facsimile No. 


Authorized officer 
Telephone No. 



Form PCT/IPEA/409 (cover sheet) (July 1998) 



INTERNATIONAL PRELIMINARY EXAMINATION REPORT 



International application No. 

PCT/EP00/02070 



I. Basis of the report 



1. With regard to the elements of the international application:* 
[ [ the international application as originally filed 
the description: 

pages 1,3-23 ^ , as originally filed 

„ orTOC , filed with the demand 

pages 



p ages 2^23 , filed with the letter of 09 March 2001 (09.03.2001) 

the claims: 

p ages ^ , as originally filed 

pages , as amended (together with any statement under Article 1 9 

„™ c , filed with the demand 

pdgca ^ _ . . . 

pages M7 , filed with the letter of 09 March 2001 (09.03.2001) 



the drawings: 

pages 1/5-5/5 , as originally filed 

pages _ 



, filed with the demand 



pages , filed with the letter of , 

| | the sequence listing part of the description: 

pages . as originally filed 

pages , filed with the demand 

pages ^ > filed w ith the letter of . 



2. With regard to the language, all the elements marked above were available or furnished to this Authority in the language in which 
the international application was filed, unless otherwise indicated under this item. 

These elements were available or furnished to this Authority in the following language which is: 

| | the language of a translation furnished for the purposes of international search (under Rule 23.1(b)). 
| | the language of publication of the international application (under Rule 48.3(b)). 

| | the language of the translation furnished for the purposes of international preliminary examination (under Rule 55.2 and/ 
or 55.3). 

3. With regard to any nucleotide and/or amino acid sequence disclosed in the international application, the international 
preliminary examination was carried out on the basis of the sequence listing: 

| 1 contained in the international application in written form. 

| | filed together with the international application in computer readable form. 

| | furnished subsequently to this Authority in written form. 

| | furnished subsequently to this Authority in computer readable form. 

| | The statement that the subsequently furnished written sequence listing does not go beyond the disclosure in the 

international application as filed has been furnished. 
[ | The statement that the information recorded in computer readable form is identical to the written sequence listing has 

been furnished. 

4. I 1 The amendments have resulted in the cancellation of: 

1 | the description, pages 

I I the claims, Nos. 

I 1 the drawings, sheets/fig 

□ This report has been established as if (some of) the amendments had not been made, since they have been considered to go 
beyond the disclosure as filed, as indicated in the Supplemental Box (Rule 70.2(c)).** 

* Replacement sheets which have been furnished to the receiving Office in response to an invitation under Article 14 are rffr™* to 
in this report as "originally filed" and are not annexed to this report since they do not contain amendments (Rule 70.16 
and 70.17). 

+*Any replacement sheet containing such amendments must be referred to under item 1 and annexed to this report. 
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V. Reasoned statement under Article 35(2) with regard to novelty, inventive step or industrial applicability; 
citations and explanations supporting such statement 



1 . Statement 

Novelty (N) 

Inventive step (IS) 
Industrial applicability (IA) 



Claims 
Claims 

Claims 
Claims 

Claims 
Claims 



1-17 



1-17 



1-17 



YES 
NO 
YES 
NO 

YES 
NO 



2. Citations and explanations 

Citations 



This international preliminary examination report 
makes reference to the following document: 

Dl: EP-A-0 817 422. 

The present international application relates to a 
" method for operating a telecommunications network " 
as per the preamble to Claim 1, a " network element 
for operating a telecommunications network" as per 
the preamble to Claim 16, and a corresponding 
" telecommunications network" as per Claim 17. 



1 . 1 Basis of and background to the present invention: 

A network element of the telecommunications network 
has a control computer with a plurality of 
application programs which, when implemented, 
operate application objects. A connection is 
established between an external operating computer 
and said control computer, the control computer 
being serviced via said connection. 

If the application programmes are developed further 
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in the control computer, then it must be guaranteed 
that application objects which are regarded by the 
operating computer as belonging to a certain class 
can also be processed by said operating computer if 
such objects were assigned to a different class , 
i.e. a substitute class , in the developed 
application programme . 

1 . 2 Prior art : 

(a) CCITT X.720 (01/92), section 5.2.3, " allomorphism" 

The cited standard proposes a programming technique 
for application programmes that takes allomorphism 
into account, i.e. a certain application object in 
the application programme can be implemented by the 
operating computer as if it were an object belonging 
to the class known in the operating computer. The 
class known in the operating computer is allomorphic 
to the class actually known in the application 
programme, i.e. the substitute class . 

(b) Document Dl also describes a method for "managing" 
objects. In Dl, a given first object can also 
communicate with future unknown second objects. For 
this purpose, when the first object is established, 

a so-called "abstract object" with corresponding 
interfaces is devised. If a second object unknown 
to the first object is later established, this 
second object inherits the properties and interfaces 
of the abstract object . 

2. The present international application addresses the 
technical problem of developing a " method for 
operating a telecommunications network" such that 
the application programmes are largely free of 
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matching with regard to the association between 
substitute classes and application objects. This 
should result in an efficient method for sending 
messages from an operating computer to the objects 
of application programmes in the control computer of 
a network element . 



3. According to the invention, this technical problem 

is solved by the features of the characterising part 
of Claim 1, according to which an interface 
programme is created in the control computer of a 
network element, said programme, when it encounters 
a message sent from an operating computer to an 
application programme in said control computer, 
converting the class designation of an object 
contained in the message and known to the operating 
computer into a substitute designation that provides 
a substitute class for the object in the application 
programme. Thus, when a message is processed in the 
application programme, the object is regarded as 
belonging to the substitute class . 

The claimed method is advantageous in that the 
operation that assigns substitute designations to 
class designations does not have to be programmed in 
each application programme, but only once at the 
central point in the interface programme . 



4. The claimed definition of the " method" , as specified 
in the features of the characterising part of 
Claim 1, is neither disclosed nor suggested by the 
prior art: 

4.1 The aforementioned X.720 standard does not include 
indications on implementation that would lead a 
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person skilled in the art to a solution as per 
Claim 1, using an interface programme to convert a 
class into a substitute class. 



4.2 Document Dl contains no suggestion of the allocation 
of substitute classes , nor the implementation of an 
interface programme before the application programme 
for converting class designations into substitute 
designations . 

Claim 1 therefore meets the requirements for novelty 
and inventive step of PCT Article .33(2) and (3). 



5. Dependent Claims 2-15 are all directly or indirectly 
dependent on Claim 1 and therefore likewise meet the 
requirements for novelty and inventive step of PCT 
Article 33(2) and (3). 



6. Claim 16, which relates to a " network element for 
operating a telecommunications network" also 
contains, by way of reference to the preceding 
method claims (i.e. by the feature " and that the 
control computer , by executing the programme, 
implements the method according to one of the 
preceding claims' ' ) , the inventive features of 
independent Claim 1 and therefore likewise meets the 
requirements for novelty and inventive step of PCT 
Article 33(2) and (3). 



7. Claim 17, which relates to a " telecommunications 
network" , is dependent on Claim 16 and therefore 
likewise meets the requirements for novelty and 
inventive step of PCT Article 33(2) and (3). 
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VERTRAG UBER DIE INTERNATIONALE ZUSAMMENARBEIT AUF DEM 

GEBIET DES PATENTWESENS 



Absender: MIT DER INTERNATIONALEN VORLAUFIGEN 
PRUFUNG BEAU FTR AGTE BEHORDE 



An: 

SIEMENS AKTIENGESELLSCHAFT 
Postfach 22 16 34 
D-80506 Munchen 
ALLEMAGNE 



r.T IPS AM MchjVRj 



eng. 1 V Juni 2001 



PCT 



MITTEILUNG UBER DIE UBERSENDUNG 
DES INTERNATIONALEN VORLAUFIGEN 
PRUFUNGSBERICHTS 

(Rege!71.1 PCT) 



Absendedatum 
(T ag/Monat/Jahr) 



08.06.2001 



Aktenzeichen des Anmelders Oder Anwalts 
99P1391P 


WICHTIGE MITTEILUNG 


Internationales Aktenzeichen 
PCT/EP00/02070 


Internationales Anmeldedatum (Tag/Monat/Jahr) 
09/03/2000 


Prioritatsdatum (Tag/Monat/Jahr) 
10/03/1999 


Anmelder 

SIEMENS AKTIENGESELLSCHAFT et al. 





1 . Dem Anmelder wird mitgeteilt, daB ihm die mit der internationalen vorlaufigen Prufung beauftragte Behorde 
hiermit den zu der internationalen Anmeldung erstellten internationalen vorlaufigen Prufungsbericht, 
gegebenenfalls mit den dazugehorigen Anlagen, ubermittelt. 



2. Eine Kopie des Berichts wird - gegebenenfalls mit den dazugehorigen Anlagen - dem Internationalen Buro zur 
Weiterleitung an alle ausgewahlten Amter ubermittelt. 



3. Auf Wunsch eines ausgewahlten Amts wird das Internationale Buro eine Ubersetzung des Berichts (jedoch 
nicht der Anlagen) ins Englische anfertigen und diesem Amt ubermitteln. 



4. ERINNERUNG 

Zum Eintritt in die nationale Phase hat der Anmelder vor jedem ausgewahlten Amt innerhalb von 30 Monaten 
ab dem Prioritatsdatum (oder in manchen Amtern noch spater) bestimmte Handlungen (Einreichung von 
Ubersetzungen und Entrichtung nationaler Gebuhren) vorzunehmen (Artikel 39 (1)) (siehe auch die durch das 
Internationale Buro im Formblatt PCT/IB/301 ubermittelte Information). 

1st einem ausgewahlten Amt eine Ubersetzung der internationalen Anmeldung zu ubermitteln, so muB diese 
Ubersetzung auch Ubersetzungen aller Anlagen zum internationalen vorlaufigen Prufungsbericht enthalten. Es 
ist Aufgabe des Anmelders, solche Obersetzungen anzufertigen und den betroffenen ausgewahlten Amtern 
direkt zuzuleiten. 

Weitere Einzelheiten zu den maBgebenden Fristen und Erfordernissen der ausgewahlten Amter sind Band II 
des PCT-Leitfadens fur Anmelder zu entnehmen. 



Name und Postanschrift der mit der internationalen Prufung 
beauftragten Behorde 

Europaisches Patentamt 
D-80298 Munchen 

Tel. +49 89 2399 - 0 Tx: 523656 epmu d 
Fax: +49 89 2399 - 4465 



Bevollmachtigter Bediensteter 
Finnie, A 

Tel. +49 89 2399-8251 



// 
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MITTEILUNG UBER DIE OBERMITTLUNG DES 
INTERNATIONALEN RECHERCHENBERICHTS 
ODER DER ERKLARUNG 

(Regel 44.1 PCT) 



Absendedaturr. 
(T ag/Monat/Jahr) 



19/05/2000 



Aktenzeichen des AnmeJders Oder Anwalts 

99P1391P 



WEITERES VORGEHEN 



siehe Punkte 1 und 4 untsn 



Internationales Aktenzeichen 

PCT/EP 00/02070 



Internationales Anmeldedatum 
(TasyMonat/Jahr) Q9/03/2000 



Anmetder 

SIEMENS AKTIENGESELLSCHAFT 



1 . [J] Dem Anmelder wird mitgeteirt, daB der Internationale Recherchenbericht erstellt wurde und ihm hiermit ubermitielt wird. 

Elnrelchung von Anderungen und einer Erklarung nach ArUkel 19: 

Der Anmelder kann auf eigenen Wunsch die Anspruche der intemationalen Anmeldung an dem (siehe Regel 46): 

Bis wann slnd Anderungen elnzurelchen? 

Die Frist zur Einretchung solcher Anderungen betragt ublicherweise zwei Monate ab der ObermitUung des 
intemationalen Recherchenberichts; weitere Einzelheiten sind den Anmerkungen auf dem Beiblatt zu entnehmen. 

Wo slnd Anderungen elnzurelchen? 

Unmrttelbar beim Intemationalen Buro der WIPO, 34, CHEMIN des Colombettes, CH-121 1 Gent 20, 
Telefaxnr.: (41-22) 740.14.35 

Nat) ere Hlnweise sind den Anmerkungen auf dem Beiblatt zu entnehmen. 

2. r~| Dem Anmelder wird mrtgeteirt, daB kein intemationaler Recherchenbericht erstellt wird und daB ihm hiermit die Erklarung nach 

Artikel 17(2)a) ubermfttelt wird. 



3. 



I I Hlnslchtllch des WIderspruchs gegen die Entrichtung einer zusatzlichen Gebuhr (zusatzlicher Gebuhren) nach Regel 40.2 wird 
' — ' dem Anmelder mitgeteilt, daB 

I | der Widerspruch und die Entscheidung hieruber zusammen mit seinem Antrag auf Obermittiung des Wortlauts sowohl des 
1 — 1 Widerspruchs als auch der Entscheidung hieruber an die Bestimmungsamter dem Intemationalen Buro ubermittert worden 
sind. 



□ 

Wei teres Vorgehen: 



noch keine Entscheidung uber den Widerspruch vorliegt; der Anmelder wird benachrichtigt sobald eine Entscheidung 
getroffen wurde. 



Der Anmelder wird auf folgendes aufmerksam gemacht 



Kurz nach Ablaut von 16 Monaten seit dem Priorttatsdatum wird die international Anmeldung vom Intemationalen Buro veroffentT 
licht. Winder Anmelder die Veroffentlichung verhindem oder auf einen spateren Zeitpunkt verschieben, so muB gemaB Regel 90 ^ 
bzw. 90tt3 vor AbschluS der technischen Vorbereitungen fur die intemationaJe Verdffentlichung eine Erklarung uber tie Zurucknah- 
me der intemationalen Anmeldung Oder des Prioritatsanspruchs beim Intemationalen Buro eingehen. 

Innerhalb von 19 Monaten seit dem Prioritatsdatum ist ein Antrag auf intemationaJe vorlaufige Prufunqeinzureichen, wenn der 
Anmelder den Eintritt in c5e nationale Phase bis zu 30 Monaten seit dem Prioritatsdatum (in manchen Am tern sogar noch langer) 
verschieben mochte. 

Innerhalb von 20 Monaten seit dem Prioritatsdatum muB der Anmelder die fur den Eintritt in die nationale Phase vorgeschriebenen 
Handlungen vor alien Bestimmungsamtem vomehmen, die nicht innerhalb von 19 Monaten seit dem Prioritatsdatum in der 
Anmeldung Oder einer nachtraglichen Auswahlerklarung ausgewahrt wurden oder nicht ausgewahtt werden konnten, da fur sie 
Kaprtel II des Vertrages nicht verbindlich ist. 





Name und Postanschrtft der Intemationalen Recherchen be horde 

Europaisches Paten tarn t T P.B. 5818 Paten tiaan 2 
Jltt NL-2280 HV Rijswijk 
WJI Tel. (+31-70) 340-2040, Tx. 31 651 epo nl, 
~— ' Fax: (+31-70) 340-3016 


Bevollmachtigter Bediensteter 

Theresia Van Deursen 
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ANMERKUNGEN ZU FORMBLATT PCT/ISA/220 



Diese Anmerkungen sollen grundlegende Hinweise zur Einreiehung von Anderungen gemaG Artikel 19 geben. Dioaen Anmerkungen 
Itegen die Erfordernisse des Vert rag 3 Ober die Internationale Zusammenarbeit auf dem Gebie! des Patentwesens (PCT), der AusfQhrungs- 
ordnung und der Verwaitungsrichtlinien zu d»e9em Vert rag zugrunde. Bei Abweichungen zwischen dies en Anmerkungen und 
obengenannten Text en sind letztere maflgebend. Nahere Einzelheiten sinddem PCT-Leitfaden tor Anmelder, einer Verdffentlichung der 
WIPO, zu errtnehmen. 

Die in dies en Anmerkungen verwendeten Beg riff e "ArtikeC, "Regel" und "Abschnitt" bezrehen sich jeweils auf die Bestimmungen des 
PCT-Vertrags, der PCT-Ausfuhrungsordnung hzw. der PCT-VerwaJtungarichtlinien. 

hinweise zu Anderungen gemAss artikel 19 

Nach ErhaJt des intemationaien Recherchenberichts hat der Anmelder die Mfiglichkeit, einmal die AnsprOche der intemationaJen 
Anmeldung zu andern. Ea ist jedoch zu betonen, dafl, da atte Teile der intemationalen An m el dung (AnsprOche, Beachreibung und 
Zeichnunaen) wan rend des intemationalen vorlaufigen PrQfungsverfahrens geandert werden kdnnen, normaierweise keine Notwendigkeit 
besteht, Anderungen der AnsprOche nach Artikel 1 9 einzureichen, auBer wenn der Anmelder z.B. zum Z we eke eines vorlaufigen 
Schutze8 die Veroffentlichung cfieser Anspruche wunscht oder ein anderer Gnjnd fOr etne Anderung der AnsprOche vor ihrer intemationa- 
len Veroffentlichung voriiegt. We item in tst zu beach ten, da6 ein vorlauftger Schutz nur in eintgen Staalen enhaJtlich ist. 



WeJcbe Telle der Intemationalen Anmeldung kdnnen geandert warden? 

Im Rahmen von Artikel 19 kdnnen nur die Anspruche geandert werden. 

In der intemationalen Phase kdnnen die AnsprOche auch nach Artikel 34 vor der mit der intemationalen vorlaufigen PrOfung beauf- 
tragten Behdrde geandert (oder nochmals geandert) werden. Die Beschreibung und die Zeichnungen kdnnen nur nach Artikel 34 
vor der mit der intemationalen vorlaufigen PrOfung beauftragten Behorde geandert werden. 

Beim Eintritt in die nationaie Phase kdnnen alle Teile der intemationalen Anmeldung nach Artikel 28 oder gegebenenfalls Artikel 
41 geandert werden. 



Bis wann slnd Anderungen einzureichen? 

Innerhalb von zwei Monaten ab der Gbermittlung des intemationalen Recherchenberichts oder innerhalb von sechzehn Monaten ab 
dem Prion tat ad alum, je nach dem, welche Frist spater aWauft. Die Andenjngen getten jedoch als rechtzeitig eingereicht, wenn sie 
dem Intemationalen BOro nach AWauf der maGgebenden Frist, aber noch vor Abachlufl der technischen Vorberertungen fOr die 
intemationale Verdffentlichung (Regel 46.1) zugehen. 



Wo slnd die Anderungen nlcht einzureichen? 

Die Anderungen kdnnen nur beim Intemationalen BOro ( nicht aber beim Anmeldeamt oder der Intemationalen Recherchenbehdrde 
eingereicht werden (Regel 46.2). 

Falls ein Ant rag auf intemationale voiiaufige PrOfung eingereicht wurde/wird, sie he unten. 

In weicher Form kdnnen Anderungen erfolgen? 

Eine Andenjng kann erfolgen durch Streichung eines oder mehrerer ganzer Anspruche, durch Hinzufugung eines oder mehrerer 
neuer Anspruche oder durch An de rung des Wortiauts eines oder mehrerer AnsprOche in der eingereicht en Fassung. 

Fur jedes AnapruchsWatt, das sich aufgrund einer oder mehrerer Andenjngen von dem ursprOnglich eingereichten Blatt 
urrterscheidet, ist ein Ersatz blatt einzureichen. 

Alle Anspruche, die auf einem Ersatzblatt erscheinen, sind mit arabischen Ziffem zu numerieren. Wird ein Anapruch gestrichen, so 
braucben, die anderen AnsprQche nicht neu numeriert zu werden. Im Fall einer Neunumerierung sind die AnsprOche fortlaufend zu 
numerieren (VerwaJtungsrichtlinien, Abschnitt 205 b)). 

Die Anderungen slnd In der Sprache abzufassen, In der dieJntemationale Anmeldung verdffentllcht wlrd. 



Welche Untertagen slnd den Anderungen belzufOgen? 
Beglettschreiben (Abschnitt 205 b)): 

Die Andenjngen sind mit einem Begleitschreiben einzureichen. 

Oas Beglertschreiben wird nicht zusammen mit der intemationalen Anmeldung und den geanderten AnsprOchen verdffentlicht Es 
ist nicht zu verwechseln mit der "ErWarung nach Artikel 19(1)* (siehe unten, "ErWarung nach Artikel 19 (1)'). 

Das Beglettschreiben Ist nach Wahl des Anmelders In englischer oder franzdsischer Sprache abzufassen. Bei engllschspra- 
chlgen Intemationalen Anmeldungen 1st das Beglettschreiben aber ebenfalls in englischer, bei tranzdsischsprachlqen Inter- 
nationalen Anmeldungen in franzdsischer Sprache abzufassen. 9 ■ 



Anmerkungen zu Formblatt PCT/ISA/220 (Blatt 1) (Januar 1994) 

BNSOOCtD: <cXSISA220NODEP4J_> 



ANMERKUNGEN ZU FORMBLATT PCT/ISA/220 (Fortsetzung) 



lm Begleitschreiben sind die Unterschiede zwischen den AnsprOchen in der eingereichten Fassung und den geanderten AnsprOchen 
anzugeben. So tst insbesondere zu jedem Anspoich in der intemationalen Anmeldung anzugeben (gleichlautende Angaben zu 
verschiedenen AnsprOchen konnen zusammengefaftt werden), ob 

i) der Anspruch unverandert tst; 

it) der Anspruch gestrichen worden ist; 

iii) der Anspruch neu ist; 

iv) der Anspruch einen oder mehrere AnsprOche in der eingereichten Fassung ersetzt; 

v) der Anspruch auf die Teilung eine a Anspruchs in der eingereichten Fassung zurOokzufOhren ist. 



Im folgenden sind Belspteie angegeben, wle Anderungen im Begleitschreiben zu erISutem sfnd: 

1. [Wenn anstelle von ursprOnglich 48 AnsprOchen nach der An de rung einiger AnsprOche 51 AnsprOche existieren]: 

"Die AnsprOche 1 bis 29, 31 , 32, 34, 35, 37 bis 48 werden durch geanderte AnsprOche gleicher Numeherung ersetzt; AnsprOche 
30, 33 und 36 unverandert; neue AnsprOche 49 bis 51 hinzugefOgt." 

2. [Wenn anstelle von ursprOnglich 1 5 AnsprOchen nach der An de rung alter AnsprOche 1 1 AnsprOche existieren]: 
"Geanderte AnsprOche 1 bis 1 1 treten an die Stelfe der AnsprOche 1 bis 1 5." 

3. [Wenn ursprOnglich 14 AnsprOche existierten und die Anderungen dahn best e hen, daft einige AnsprOche gestrichen werden und 
neue AnsprOche hinzugefOgt werden]: 

AnsprOche 1 bis 6 und 14 unverandert; AnsprOche 7 bis 13 gestrichen; neue AnsprOche 15, 16 und 1 7 hinzugefOgt. "Oder" An- 
sprOche 7 bis 13 gestnchen; neue AnsprOche 15, 16 und 17 hinzugefOgt; alle Obrigen AnsprOche unverandert." 

4. [Wenn verschiedene Arten von Anderungen durchgefOhrt werden]: 

"AnsprOche 1-10 unverandert; AnsprOche 1 1 bis 13, 18 und 19 gestrichen; AnsprOche 1 4, 15 und 16 durch geanderten An- 
spruch 14 ersetzt; Anspruch 17 in geanderte AnsprOche 15, 16 und 17 unterteilt; neue AnsprOche 20 und 21 hinzugefOgt." 

"ErWarung nach Artlkei 19(1)" (Regei 46.4) 

Den Anderungen kann eine Erklarung beigefOgt werden, mrt der die Anderungen ertautert und ihre Auswirkungen auf die 
Beschreibung und die Zeichnungen dargeiegt werden (die nichl nach Artikel 1 9 (1 ) geandert werden konnen). 

Die Erklarung wird zusammen mrt der intemationalen Anmeldung und den geanderten AnsprOchen veroffentltcht. 
Sle ist In der Sprache abzufasaen, in der die intemationalen Anmeldung verdffentllcht wird. 

Sie muR kurz gehaJten sein und darf, wenn in engltscher Sprache abgefaftt oder ins Englische Obersetzt, nicht mehr ais 500 
Wdrter umf assen 

Die Erklarung ist nicht zu verwechseln mrt dem Begleitschreiben, das auf die Unterschiede zwischen den AnsprOchen in der 
eingereichten Fassung und den geanderten AnsprOchen hinweist, und ersetzt letzteres nicht, Sie ist auf einem gesonderten Blatt 
einzureichen und in der Oberschrift aJs solche zu kennzeichnen, vorzugsweise mit den Worten "ErWarung nach Artikel 19 (1)*. 

Die Erklarung darf keine herabeetzenden AuRerungen uber den intemationalen Recherchenbericht oder die Bedeutung von in dem 
Bericht angefOhrten Verfiffentlichungen enthalten. Sie darf auf im intemationalen Recherchenbericht angefQhrte Verdffentlichun- 
gen, de sich auf einen bestimmten Anspruch beziehen, nur im Zusammenhang mit einer An de rung dieses Anspruchs Bezug 
nehmen. 



Auswirkungen eines bereJts gestellten Ant rags auf Internationale voriaufige PrOfung 

1st zum Zeitpunkt der Einreichung von Anderungen nach Artikel 19 bereits ein Antrag auf irrternationale voriaufige PrOfung 
gestellt worden, so sollte der Anmelder in seinem Interesse gleichzeitig mit der Einreichung der Anderungen beim Internal ion alen 
BOro auch eine Kopie der Anderungen bei der mit der intemationalen vorlaufigen PrOfung beauftraaen Be horde einreichen fsiehe 
Regel62.2a) l ersterSatz). 1 



Auswirkungen von Anderungen hlnsichttich der Gbersetzung dertntematlonalen Anmeldung beim Eintrttt In die 
natlonale Phase 

Der Anmelder wird darauf hingewiesen, daB bei Eintritt in die nationale Phase moglicherweise an start oder zusaizlich zu der Uber- 
setzung der AnsprOche in der eingereichten Fassung eine Ubersetzung der nach Artikel 19 geanderten AnsprOche an die 
bestimmten/ausgewahtten Amter zu Obermitteln ist. 

Nahere Einzelheiten Ober die Erfordemisse jedes bestimmten/ausgewahften Amts sind Band II des PCT-Leitfadens fOr Anmelder 
zu ent nehmen 
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99P1391P 


siehe Mitteilung Ober die Ubersendung des internationalen 
WEITERES VORGEHEN vorlaufigen PrOfungsberichts (Formblatt PCT/IPEA/416) 


Internationales Aktenzeichen 
PCT/EPOO/02070 


Internationales Anmeldedatum (T ag/Monat/Jahr) 
09/03/2000 


Prioritatsdatum (Tag/Monat/Tag) 
10/03/1999 


Internationale Patentklassifikation (IPK) Oder i 
H04Q3/00 


rationale Klassifikation und IPK 


Anmelder 

SIEMENS AKTIENGESELLSCHAFT et al. 



1 . Dieser internationale vorlaufige PrOfungsbericht wurde von der mit der internationalen vorlaufigen Pruf ung beauftragten 
Behorde erstellt und wird dem Anmelder gemaB Artikel 36 ubermittelt. 

2. Dieser BERICHT umfaBt insgesamt 6 Blatter einschlieBlich dieses Deckblatts. 

H AuBerdem liegen dem Bericht ANLAGEN bei; dabei handelt es sich urn Blatter mit Beschreibungen, Anspruchen 
und/oder Zeichnungen, die geandert wurden und diesem Bericht zugrunde liegen, und/oder Blatter mit vor dieser 
Behorde vorgenommenen Berichtigungen (siehe Regel 70.16 und Abschnitt 607 der Verwaltungsrichtlinien zum PCT). 

Diese Anlagen umfassen insgesamt 7 Blatter. 



3. Dieser Bericht enthalt Angaben zu folgenden Punkten: 



I 


IS 


II 


□ 


III 


□ 


IV 


□ 


V 




VI 


□ 


VII 


□ 


VIII 


□ 



Grundlage des Berichts 
Prioritat 

Keine Erstellung eines Gutachtens Ober Neuheit, erfinderische Tatigkeit und gewerbliche Anwendbarkeit 
Mangelnde Einheitlichkeit der Erfindung 

Begrundete Feststellung nach Artikel 35(2) hinsichtlich der Neuheit, der erfinderischen Tatigkeit und der 
gewerblichen Anwendbarkeit; Unterlagen und Erklarungen zur Stutzung dieser Feststellung 

Bestimmte angefuhrte Unterlagen 

Bestimmte Mangel der internationalen Anmeldung 

Bestimmte Bemerkungen zur internationalen Anmeldung 



Datum der Einreichung des Antrags 



09/10/2000 



Name und Postanschrift der mit der internationalen vorlaufigen 
Prufung beauftragten Behorde: 
Europaisches Patentamt 

D-80298 Munchen 
Tel. +49 89 2399 - 0 Tx: 523656 epmu d 

Fax: +49 89 2399 - 4465 



Datum der Fertigsteltung dieses Berichts 



08.06.2001 



Bevollmachtigter Bediensteter 
Moll, H-P 

Tel. Nr. +49 89 2399 8243 
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I. Grundlage des Berichts 

1 . Hinsichtlich der Bestandteile der internationalen Anmeldung (Ersatzblatter, die dem Anmeldeamt auf erne 
Aufforderung nach Artikel 14 hin vorgelegt warden, gelten im Rahmen dieses Berichts afs "ursprunglich 
eingereicht" und sind ihm nicht beige fugt, weit sie keine Anderungen enthalten (Regeln 70. 16 und 70. 1 7)): 
Beschreibung, Seiten: 

1 ,3-23 ursprungliche Fassung 

2 ( 2a eingegangen am 12/03/2001 mit Schreiben vom 09/03/2001 



Patentanspruche, Nr.: 

1-17 eingegangen am 12/03/2001 mit Schreiben vom 09/03/2001 



Zeichnungen, Blatter: 

1/5-5/5 ursprungliche Fassung 



2. Hinsichtlich der Sprache: Alle vorstehend genannten Bestandteile standen der Behorde in der Sprache, in der 
die internationale Anmeldung eingereicht worden ist, zur Verfugung oder wurden in dieser eingereicht, sofern 
unter diesem Punkt nichts anderes angegeben ist. 

Die Bestandteile standen der Behorde in der Sprache: zur Verfugung bzw. wurden in dieser Sprache 
eingereicht; dabei handelt es sich um 

□ die Sprache der Ubersetzung, die fur die Zwecke der internationalen Recherche eingereicht worden ist (nach 
Regel 23.1(b)). 

□ die Veroffentlichungssprache der internationalen Anmeldung (nach Regel 48.3(b)). 

□ die Sprache der Ubersetzung, die fur die Zwecke der internationalen vorlaufigen Prufung eingereicht worden 
ist (nach Regel 55.2 und/oder 55.3). 



3. Hinsichtlich der in der internationalen Anmeldung offenbarten Nucleotid- und/oder Aminosauresequenz ist die 
internationale vorlaufige Prufung auf der Grundlage des Sequenzprotokolls durchgefuhrt worden, das: 

□ in der internationalen Anmeldung in schriftlicher Form enthalten ist. 

□ zusammen mit der internationalen Anmeldung in computerlesbarer Form eingereicht worden ist. 

□ bei der Behorde nachtraglich in schriftlicher Form eingereicht worden ist. 

□ bei der Behorde nachtraglich in computerlesbarer Form eingereicht worden ist. 

□ Die Erklarung, daB das nachtraglich eingereichte schriftliche Sequenzprotokoll nicht uber den 
Offenbarungsgehalt der internationalen Anmeldung im Anmeldezeitpunkt hinausgeht, wurde vorgelegt. 

□ Die Erklarung, daB die in computerlesbarer Form erfassten Informationen dem schriftlichen 
Sequenzprotokoll entsprechen, wurde vorgelegt. 



i 
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4. Aufgrund der Anderungen sind folgende Unterlagen fortgefallen: 

□ Beschreibung, Seiten: 

□ Anspruche, Nr.: 

□ Zeichnungen, Blatt: 

5. □ Dieser Bericht ist ohne Berucksichtigung (von einigen) der Anderungen erstellt worden, da diese aus den 

angegebenen Grunden nach Auffassung der Behorde uber den Offenbarungsgehalt in der ursprunglich 
eingereichten Fassung hinausgehen (Regel 70.2(c)). 

(Auf Ersatzblatter, die solche Anderungen enthalten, ist unter Punkt 1 hinzuweisen;sie sind diesem Bericht 
beizufugen). 



6. Etwaige zusatzliche Bemerkungen: 



V. Begrundete Feststellung nach Artikel 35(2) hinsichtlich der Neuheit, der erfinderischen Tatigkeit und der 
gewerblichen Anwendbarkeit; Unterlagen und Erklarungen zur Stutzung dieser Feststellung 

1. Feststellung 

Neuheit (N) Ja: Anspruche 1-17 

Nein: Anspruche 

Erfinderische Tatigkeit (ET) Ja: Anspruche 1 -1 7 

Nein: Anspruche 

Gewerbliche Anwendbarkeit (GA) Ja: Anspruche 1-17 

Nein: Anspruche 



2. Unterlagen und Erklarungen 
siehe Beiblatt 
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Anaefuhrte Unterlaqen 

1 . In diesem Internationalen Vorlaufiaen Prufungsbericht wird auf das folgende 
Dokument verwiesen: 

D1: EP- A -0 817 422 
Zu Punkt V 

Begrundete Feststellung nach Artikel 35(2) hinsichtlich der Neuheit, der 
erfinderischen Tatigkeit und der gewerblichen Anwendbarkeit; Unterlagen und 
Erklarungen zur Stutzung dieser Feststellung 

1 . Die vorliegende Internationale Anmeldung betrifft ein " Verfahren zum Betreiben 
eines Telekommunikationsnetzes " gemaB Oberbegriff des Anspruchs 1, ein 
" Netzelement zum Betreiben eines Telekommunikationsnetzes " gemaB 
Oberbegriff des Anspruchs 16 sowie ein entsprechendes 
" Telekommunikationsnetz " gemaB Anspruch 17. 

1.1 Grundlaae und Hinterarund der vorlieaenden Erfinduna : 

Ein Netzelement des Telekommunikationsnetzes verfugt uber einen 
Steuerrechner mit mehreren Anwendungsprogrammen, bei deren Ausfuhren 
Anwendungsobjekte bearbeitet werden. Zwischen einem externen Bedienrechner 
und diesem Steuerrechner wird eine Verbindung aufgebaut uber die der 
Steuerrechner gewartet wird. 

Werden nun die Anwendungsprogramme im Steuerrechner weiterentwickelt, so 
muB gewahrleistet sein, daB Anwendungsobjekte, die vom Bedienrechner als zu 
einer bestimmten Klasse zugehorig angesehen werden, auch dann von diesem 
Bedienrechner aus behandelt werden konnen, wenn diese Objekte im 
weiterentwickelten Anwendungsprogramm einer geanderten Klasse . d.h. einer 
Ersatzklasse . zugeordnet wurden. 

1.2 Stand der Technik : 

(a) CCITT X.720 (01/92), Abschnitt 5.2.3, " Allomorphie " 

Im genannten Standard wird fur die Anwendungsprogramme eine 
Programmiertechnik vorgeschlagen, die Allomorphie berucksichtigt, d.h. ein 
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bestimmtes Anwendungsobjekt im Anwendungsprogramm kann vom 
Bedienrechner aus so gefuhrt werden, als ware es ein Objekt der irn 
Bedienrechner bekannten Klasse. Die im Bedienrechner bekannte Klasse ist zur 
tatsachlich im Anwendungsprogramm bekannten Klasse, d.h. der Ersatzklasse . 
allomorph . 

(b) Das Dokument D1 beschreibt ebenfalls ein Verfahren zum "Managen" von 
Objekten. In D1 wird erreicht, daB ein gegebenes erstes Objekt auch mit 
unbekannten zukunftigen zweiten Objekten kommunizieren kann. Dazu wird bei 
Einrichtung des ersten Objekts ein sogenanntes abstraktes Objekt ("abstract 
object") mit entsprechenden Schnittstellen geschaffen. Wird nun spater ein 
zweites Objekt, welches dem ersten Objekt unbekannt ist eingerichtet, so erbt 
dieses zweite Objekt die Eigenschaften und Schnittstellen des abstrakten Objekts. 

2. Es ist die technische Aufaabe der vorliegenden International Anmeldunq . ein 
" Verfahren zum Betreiben eines Telekommunikationsnetzes " derart 
bereitzustellen, daB die Anwendungprogramme weitestgehend von 
Anpassungsaufgaben hinsichtlich der Zuordnung von Ersatzklassen zu 
Anwendungsobjekten entlastet werden. Somit soli ein effizientes Verfahren zum 
Senden von Nachrichten von einem Bedienrechner an die Objekte von 
Anwendungsprogrammen im Steuerrechner eines Netzelementes bereitgestellt 
werden. 

3. ErfindungsgemaB wird diese technische Aufaabe durch die Merkmale des 
kennzeichnenden Teils des Anspruchs 1 derart gelost, daB im Steuerrechner 
eines Netzelements ein Schnittstellenproqramm bereitgestellt wird, welches bei 
Eintreffen einer von einem Bedienrechner an ein Anwendungsprogramm in 
diesem Steuerrechner gerichteten Nachricht, das in dieser Nachricht enthaltene 
und dem Bedienrechner bekannte Klassenkennzeichen eines Objekts in ein 
Ersatzkennzeichen umwandelt, welches eine Ersatzklasse des Objekts im 
Anwendungsprogramm angibt. Das Objekt wird somit bei Abarbeiten einer 
Nachricht im Anwendungsprogramm als Objekt der Ersatzklasse betrachtet. 

Das erfindungsgemaBe Verfahren hat den Vorteil, daB die Funktion der 
Zuordnung von Ersatzkennzeichen zu Klassenkennzeichen nicht in jedem 
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4.1 



4.2 



5. 



6. 



Anwendungsprogramm, sondem nur einmal an zentraler Stelle im 
Schnittstellenproqramm programmiert werden muB. 

Die erfindungsgemaBe Definition des " Verfahrens ". wie es in den Merkmalen des 
kennzeichnenden Teils des Anspruchs 1 festgelegt ist, wird durch den Stand der 
Technik weder offenbart noch nahegelegt: 

Dem genannten X.720-Standard sind keine Implementierungshinweise zu 
entnehmen, die einen Fachmann zu einer Losung gemaB Anspruch 1 mit einem 
Schnittstellenproaramm zur Umsetzung einer Klasse in eine Ersatzklasse leiten 
wurden. 

Dem Dokument D1 sind weder Hinweise auf die Zuordnung von Ersatzklassen . 
noch auf die Implementierung eines den Anwendungsprogrammen vorgelagerten 
Schnittstellenproqramms zur Umsetzung von Ktassenkennzeichen in 
Ersatzkennzeichen zu entnehmen. 

Der Anspruch 1 erfullt daher die Erfordernisse des Artikels 33(2) und (3) PCT 
hinsichtlich Neuheit sowie erfinderischer Tatigkeit. 

Die abhangigen Anspruche 2-15, alle direkt oder indirekt von Anspruch 1 
abhangig, erfullen folglich ebenfalls die Erfordernisse des Artikels 33(2) und (3) 
PCT hinsichtlich Neuheit sowie erfinderischer Tatigkeit. 

Der auf ein " Netzelement zum Betreiben eines Telekommunikationsnetzes " 
gerichtete Anspruch 16 enthalt durch die Bezugnahme auf die vorhergehenden 
Verfahrensanspruche, d.h. durch das Merkmal " .... und da8 der Steuerrechner 
durch das Abarbeiten der Programme das Verfahren nach einem der 
vorhergehenden Anspruche durchfuhrf \ auch die erfinderischen Merkmale des 
unabhangigen Anspruchs 1 und erfullt folglich ebenfalls die Erfordernisse des 
Artikels 33(2) und (3) PCT hinsichtlich Neuheit sowie erfinderischer Tatigkeit. 

Der auf ein " Telekommunikationsnetz " gerichtete Anspruch 17 erfullt aufgrund 
seiner Abhangigkeit von Anspruch 16 ebenfalls die Erfordernisse des Artikels 
33(2) und (3) PCT hinsichtlich Neuheit sowie erfinderischer Tatigkeit. 
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bau solcher offenen Systeme. Zum Fuhren des Tk- N etz es soil 
ein separates Fiihrungsnetz verwendet werden. Dxe Schnxttstel- 
len zwischen Bedienrechner und Vermittlungseinrichtung sxnd 
in Protokollen 01, Q2 und Q3 standard! s i ert . 

Die Anwendungsobjekte sind als Objekte einer objektorientier- 
ten Sprache definiert, z.B. in der Sprache C ++ Oder CHILL. 
Werden die Anwendungsprogramme weiterentwickelt, so muB ge 
wahrleistet werden, daB das Fiihrungsnetz auch mit den neuen 
10- Anwendungsprogrammen fehlerfrei arbeitet. Das bedeutet xnsbe- 
sondere, daB Anwendungsobjekte, die vom Bedienrechner als zu 
einer ursprtinglichen Klasse gehorend angesehen werden, nxcht 
ohne weiteres einer geanderten Ersatzklasse zugeordnet werden 



konnen , 



Dieses Problem wird xm CCITT-Standard X.720 (01/92) - 'Infor- 
mation Technology - Open Systems Interconnection - Structure 
of Management Information: Management Information Model - xm 
Abschnitt 5.2.1 angesprochen. Im Abschnitt 5.2.3 des Stan- 
20 dards X.720 werden zwei Methoden zum Losen des Problems vor- 
gegeben. Bei der ersten Methode wird auf der Seite des Anwen- 
dungsprogramms eine Programmiertechnik verwendet, dxe Allo- 
morphie berucksichtigt . Allomorphie ist die Fahigkeit exnes 
bestimmten Anwendungsobjektes der Ersatzklasse so gefuhrt zu 
25 werden, als ware es ein Objekt der ursprtinglichen Klasse, 

wenn diese Fahigkeit durch MaBnahmen auf der Seite des Anwen- 
dungsprogramms entsteht. Die andere Methode besteht darxn, 
daB auf der Seite des Bedienrechners MaBnahmen getrof fen wer- 
den, welche auch bei einer Weiterentwicklung des Anwendungs- 
30 programs ein Zusammenarbeiten zwischen Bedienrechner und An- 
wendungsprograinm ermoglichen. 

Aus der europaischen Patentanmeldung EP-A-0 817 422 ist ein 
verfahren zum Implementieren von gefuhrten Objekten in exn 
35 Teilsystem eines gefuhrten Systems in einem Netzwerk bekannt, 
wobei mxndestens ein Fuhrungssystem und ein geftlhrtes System 
vorhanden sind. Die gefuhrten Objekte werden unabhangxg von 
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anderen Teilsystemen implementiert, ohne den Typ der Objekte 
in den anderen Teilsystemen zu kennen. Sie konnen mit anderen 
Objekten verbunden sein sowie Nachrichten zu ihnen ubertra- 
gen. Dazu wird ein erstes Objekt zur Kooperation mit einem 
5 abstrakten Objekt erzeugt. Das abstrakte Objekt hat eine de- 
finierte Schnittstelle, die mit Hilfe des ersten Objekts auf- 
gerufen wird und die einem zweiten Objekt das abstrakte Ob- 
jekt vererbt, wobei das erzeugte zweite Objekt unbekannt mit 
dem ersten ist und wobei das zweite Objekt zur Kooperation 

10 mit dem ersten Objekt bestimmt ist. Das erste Objekt, das mit 
dem zweiten Objekt kooperiert, betrachtet das zweite Objekt 
wie ein Objekt des abstrakten Typs . Jedoch wird bei diesem 
aus der EP-A- 0 817 422 bekannten Verfahren keine Program- 
miertechnik verwendet, die die Allomorphie gemaB des Ab- 

15 schnittes 5.2.3 des Standards X.720 beriicksichtigt. 

Es ist Aufgabe der Erfindung zum Betreiben eines Telekommuni- 
kationsnetzes ein einfaches Verfahren anzugeben, bei dem Al- 
lomorphie beriicksichtigt wird. 

20 
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Patentansprtiche 

1. Verfahren zum Betreiben eines Telekommunikationsnetzes 

( 10 ' 12) ' ■ „ , 

5 bei dem ein Netzelement (16) an einem Netzknoten ernes Tele- 
kommunikationsnetzes (12) von einem Steuerrechner (36) ge- 
steuert wird, 

im Steuerrechner (36) neben dem Betriebssystem mindestens em 
Schnittstellenprogramm (100) sowie mehrere Anwendungsprogram- 
10 me (102, 104) gespeichert sind, bei deren Ausfuhren Anwen- 
dungsobjekte (a2, a3) bearbeitet werden, 

die Anwendungsobjekte <a2, a3) je nach Zugeh6rigkeit zu einer 
Klasse (A, A' ) Daten mit einer vorgegebenen Datenstruktur so- 
wie vorzugsweise auch vorgegebene Verfahren zum Bearbeiten 

15 der Daten haben, 

zwischen einem Bedienrechner (24) und dem Steuerrechner (36) 
eine Verbindung aufgebaut wird, liber die der Steuerrechner 
(36) mittels mindestens einer Wartungsnachricht (WN1 bis WN3) 
gewartet wird, wobei das Schnittstellenprogramm (100) die vom 

20 Bedienrechner (24) kommenden Wartungsnachrichten (WN1 bis 
WN3) bearbeitet, 

die Wartungsnachricht (WN1 bis WN3) ein Klassenkennzeichen 
(moC) enthalt, das die Wartungsnachricht (WN1 bis WN3) einer 
Klasse (A, A' ) zuordnet, 
25 das Klassenkennzeichen (moC) der Wartungsnachricht (WN1 bis 
WN3) die im Bedienrechner bekannte Klasse (A) eines zu bear- 
beitenden Anwendungsobj ektes (a2, a3) angibt, 

beim Abarbeiten des Schnittstellenprogramms (100) anhand des 
Klassenkennzeichens (moC) ein Ersatzkennzeichen ermittelt 
30 wird, welches eine Ersatzklasse (A') angibt, der das zu bear- 
beitende Anwendungsobj ekt (a2, a3) im Netzelement (16) ange- 
hort, 

beim Abarbeiten des Schnittstellenprogramms (100) das Ersatz- 
kennzeichen (A') in eine geanderte Wartungsnachricht (WN1' 
35 bis WN2') aufgenommen wird, 
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und bei dem Bearbeiten der geanderten Wartungsnachricht (WN1' 
bis WN2') durch ein Anwendungsprogramm (102) das zu bearbei- 
tende Anwendungsobjekt (a2, a3) als Objekt der Ersatzklasse 
(A' ) bearbeitet wird. 

2. Verfahren nach einem der vorhergehenden Ansprtiche, dadurch 
gekennzeichnet, daB beim Enaitteln des Ersatzkennzeichens 
(A') eine im Speicher (122) des Steuerrechners (16) gespei- 
cherte erste Tabelle (T) verwendet wird, in der dem Klassen- 
kennzeichen (A) ein Ersatzkennzeichen (A') zugeordnet ist. 

3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, 
daB das Anwendungsprogramm (102) nach dem Bearbeiten der ge- 
anderten Wartungsnachricht (WN1' ) eine Bestatigungsnachricht 
(BN1) erzeugt, in der die beim Erzeugen des zu bearbeitenden 
Anwendungsobjekts (a2, a3) angegebene Klasse (oC) als Klas- 
senkennzeichen (moC) angegeben ist. 

4. Verfahren nach Anspruch 3, dadurch gekennzeichnefc, daB 
beim Abarbeiten des Schnittstellenprogramms (100) aus der 
Bestatigungsnachricht (BN1) eine geanderte Bestatigungsnach- 
richt (BN1' ) erzeugt wird, die nur solche Daten enthalt, die 
ein Anwendungsobjekt (a2) der Klasse (A) hat, auf die sich 
die Bestatigungsnachricht (BN1) bezieht, 

und daB die geanderte Bestatigungsnachricht (BN1' ) an den Be- 
dienrechner (24) gesendet wird. 

5. Verfahren nach Anspruch 3 Oder 4, dadurch gekennzeichnet, 
daB die beim Erzeugen des zu bearbeitenden Anwendungsob j ektes 
(a2, a3) angegebene Klasse (A, A f ) als Ursprungsklasse (oC) 
in den Daten des zu bearbeitenden Anwendungsobjekts <a2, a3) 
gesp^ichert ist, 

und daB beim Abarbeiten des Anwendungsprogramms (102) die Ur- 
sprungsklasse (oC) als Klassenkennzeichen (moC) verwendet 
wird. 



GEAENDERTES BLATT 



iy9901391 



26 



6. Verfahren nach einem der Ansprtiche 3 bis 5, dadurch ge- 
kennzeichnet, dafS die Bestatigungsnachricht (BN2 ) ein Kenn- 
zeichen (alio) enthalt, in welchem mindestens eine Klasse (A) 
bezeichnet ist, die im Bedienrechner (24) als die Klasse (A) 
bekannt ist, zu der das zu bearbeitende Anwendungsob j ekt (a2, 
a3) gehort. 

7. Verfahren nach Anspruch 6, dadurch gekennzeichnet, daB die 
Bestatigungsnachricht (BN1) neben dem Klassenkennzeichen 
(moC) ein Ursprungskennzeichen (oC) enthalt, in welchem die 
Ursprungsklasse (A, A') angegeben ist. 

8. Verfahren nach Anspruch 6 oder 7, dadurch gekennzeichnet, 
dafi mindestens eine im Bedienrechner (24) und/oder in mindes- 
tens einem anderen Bedienrechner fur das Anwendungsobjekt be- 
kannte Klasse (A) als Allomorphklasse (alio) in den Daten des 
Anwendungsob j ektes (a2, a3) gespeichert ist, 

imd daB beim Abarbeiten des Anwendungsprogramms (102) die Al- 
lomorphklasse (alio) als Hilfskennzeichen (alio) verwendet 
wird. 

9. Verfahren nach einem der Ansprtiche 4 bis 8, dadurch ge- 
kennzeichnet, dafi die bzw. eine beim Abarbeiten des Schnitt- 
stellenprogramms (100) fur den Bedienrechner (24) erzeugte 
Bestatigungsnachricht <BN1', BN2' ) das Klassenkennzeichen 
(moC) und das Ursprungskennzeichen (oC) oder das Klassenkenn- 
zeichen (moC) , das Ursprungskennzeichen (oC) und ein Kennzei- 
chen (alio), in welchem mindestens eine Klasse (A) bezeichnet 
ist, enthalt. 

10. Verfahren nach einem der vorhergehenden Anspruche, da- 
durch gekennzeichnet, daft das Netzelement eine Vermittlungs- 
stelle (16), ein Cross-Connector oder eine Konzentratorein- 
heit ist. 

11. Verfahren nach einem der vorhergehenden Anspruche, da- 
durch gekennzeichnet, dafi das Telekommunikationsnetz (12) ein 
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Festnetz, ein Mobilfunknetz oder ein Netz mit einem Festnetz- 
anteil und einem Mobil funknetzanteil ist. 

12. Verfahren nach einem der vorhergehenden Anspriiche, da- 
5 durch gekennzeichnet, dafi das Schnittstellenprogramm (100) 
weitere Schnittstellenfunktionen zwischen dem Bedienrechner 
(24) und den Anwendungsprogrammen (102, 104) ausfuhrt, 
vorzugsweise eine Ereignissteuerung zum Festlegen der Bear- 
beitungsreihenfolge der Wartungsnachrichten (WN1 bis WN3) 

10 und/oder eine Anpassung der vom Bedienrechner (24) kommenden 
Nachrichten (WN1 bis WN3) an ein Protokoll zur Nachrichten- 
ubertragung innerhalb des Steuerrechners (16), 
und/oder eine Anpassung der von den Anwendungsprogrammen 
(102, 104) kommenden Bestatigungsnachrichten (BN1, BN2) an 

15 ein vorgegebenes Protokoll zur Nachrichtenubertragung zwi- 
schen Bedienrechner (24) und Steuerrechner (16). 

13. Verfahren nach einem der vorhergehenden Anspriiche, da- 
durch gekennzeichnet, dafi ein erstes Anwendungsprogramm (102) 

20 zur Teilnehmerverwaltung, 

und/oder ein zweites Anwendungsprogramm zum Verwalten von 
Verbindungsleitungen zu anderen Vermittlungseinrichtungen, 
und/oder ein drittes Anwendungsprogramm zur Wartung der Ver- 
mittlungseinrichtungen, 

25 und/oder ein viertes Anwendungsprogramm (104) zur Verkehrs- 
messung der geschalteten Verbindungen (18) verwendet wird. 

14. Verfahren nach Anspruch 13, dadurch gekennzeichnet, dafi 
die Anwendungsobjekte (a2, a3) des ersten Anwendungsprogramms 

30 (102) fur jeweils einen Teilnehmer (Tln2, Tln3) die Teilneh- 
merdaten enthalten, vorzugsweise die Rufnummer und/oder die 
nutzbaren Telekommunikationsdienste. 

15. Verfahren nach einem der vorhergehenden Anspriiche, da- 
35 durch gekennzeichnet, dafi die Wartungsnachrichten (WN1 bis 

WN3) ein Namenskennzeichen (mol) filr den Namen des Anwen- 
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dungsobjektes (a2, a3> enthalten, auf welches sich die War- 
tungsnachricht (WN1 bis WN3) bezieht. 

16. Netzelement (16) zum Betreiben eines Telekoitnaunikat ions- 
net zes (10, 12) dadurch gekennzeichnet, daB es iiber einen 
Steuerrechner (36) verftigt, der ein Schnittstellenprogramm 

(100) und mehrere Anwendungsprogramme (102, 104) hat, und daB 
der Steuerrechner (36) durch das Abarbeiten der Programme 

(100, 102, 104) das Verfahren nach einem der vorhergehenden 

Ansprtlche durchfuhrt. 

17. Telekommunikationsnetz (10, 12), dadurch gekennzeichnet, 
daB es eine Vielzahl von Netzelementen enthalt und daB es die 
an die Netzelemente angeschlossenen Teilnehmer verbindet, wo- 
bei das Telekommunikationsnetz (10, 12) mindestens ein Netz- 
element (16) gemaB Anspruch 16 enthalt. 
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of such open systems. A separate control network is to 
be used to control the telecommunications network. The 
interfaces between the service computer and switching 
device are standardized in protocols Ql , Q2 and Q3 . 

5 

The application objects are defined as objects of an 
object-oriented language, for example in the language 
C++ or CHILL. If the application programs are 
developed, it is necessary to ensure that the control 
10 network also operates without faults with the new 
application programs. This means in particular that 
application objects which are considered by the service 
computer as belonging to an original class cannot 
readily be assigned to an amended alternative class. 

15 

This problem is mentioned in the CCITT standard X.720 
(01/92) - "Information Technology - Open Systems 
Interconnection - Structure of Management Information: 
Management Information Model" - in the section 5.2.1. 

20 In the section 5.2.3 of the standard X.720, two methods 
for solving the problem are proposed. In the first 
method, on the part of the application program, a 
programming technique is used which takes allomorphy 
into consideration. Allomorphy is the ability of a 

25 specific application object of the alternative class to 
be controlled as if it were an object of the original 
class if this ability arises as a result of measures on 
the part of the application program. The other method 
comprises taking measures on the part of the service 

3 0 computer which permit cooperation between the service 
computer and the application program even when the 
application program is developed. 

The object of the invention is to disclose a simple 
35 method for operating a telecommunications network in 
which allomorphy is taken into consideration. 
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Patent claims 



1 . 

5 
10 
15 
20 
25 
30 



A method for operating a telecommunications 
network (10, 12), in which a network element (16) 
at a network node of a telecommunications network 
(12) is controlled by a control computer (36), a 
plurality of application programs (102, 104) are 
stored in the control computer (36) in addition to 
the operating system, during the execution of 
which application programs (102, 104) application 
objects (a2, a3) are processed, the application 
objects (a2, a3) having, depending on their 
membership of a class (A, A' ) , data with a 
predefined data structure and preferably also 
predefined methods for processing the data, a link 
via which maintenance is performed on the control 
computer (36) by means of at least one maintenance 
message (WN1 to WN3) is set up between a service 
computer (24) and the control computer (36) , the 
maintenance message (WN1 to WN3 ) contains a class 
identifier . (moC) which assigns the maintenance 
message (WN1 to WN3) to a class (A, A' ) , the class 
identifier (moC) of the maintenance message (WN1 
to WN3 ) specifies the class (A), known in the 
service computer, of an application object (a2, 
a3) to be processed, when the interface program 
(100) is processed with reference to the class 
identifier (moC) an alternative identifier is 
determined which indicates an alternative class 
(A') to which the application object (a2, a3) to 
be processed belongs in the network element (16) , 
when the interface program (100) is processed the 
alternative identifier (A' ) is incorporated into 
an amended maintenance message (WN1' to WN2 ' ) , and 
in which, when the amended maintenance message 
(WN1' to WN2 ' ) is processed, the application 
object (a2, a3) to be processed is processed as an 
object of the alternative class (A') by an 
application program (102) . 
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The method as claimed in one of the preceding 
claims, characterized in that, when the 



5 

3 . 

10 
15 

4 . 

20 
25 

5 . 

30 



alternative identifier (A' ) is determined, a first 
table (T) which is stored in the memory (122) of 
the control computer (16) is used, in which table 
(T) an alternative identifier (A' ) is assigned to 
the class identifier (A) . 

The method as claimed in claim 1 or 2, 
characterized in that, after the processing of the 
amended maintenance message (WN1'), the 
application program (102) generates a confirmation 
message (BN1) in which the class (oC) specified 
when the application object (a2, a3) to be 
processed was generated is specified. 

The method as claimed in claim 3, characterized in 
that, when the interface program (100) is 
processed, an amended confirmation message (BN1') 
is generated from the confirmation message (BN1) , 
said amended confirmation message (BN1') 
containing only data which has an application 
object (a2) of the class (A) to which the 
confirmation message (BN1) relates, and in that 
the amended confirmation message (BN1 7 ) is 
transmitted to the service computer (24). 

The method as claimed in claim 3 or 4, 
characterized in that the class (A, A' ) specified 
when the application object (a2, a3) to be 
processed is generated is stored as an origin 
class (oC) in the data of the application object 
(a2, a3) to be processed, and in that, when the 
application program (102) is processed, the origin 
class (oC) is used as a class identifier (moC) . 



6. 



The method as claimed in one of claims 3 to 5, 
characterized in that the confirmation message 
(BN1) contains an auxiliary identifier (alio) in 
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which at least one class (A) is designated which 
is known in the service computer (24) and/or in at 
least one other service computer as the 



class (A) to which the application object (a2, a3) 
to be processed belongs, preferably at least the 
class (A)., known in the service computer (24) , of 
the application object (a2, a3) to be processed. 

The method as claimed in claim 6, characterized in 
that the confirmation message (BN1) contains, in 
addition to the class identifier (moC) , an origin 
identifier (oC) in which the origin class (A # A' ) 
is specified. 

The method as claimed in claim 6 or 7, 
characterized in that at least one class (A) known 
in the service computer (24) and/or in at least 
one other service computer for the application 
object is stored as an allomorph class (alio) in 
the data of the application object (a2, a3), and 
in that, when the application program (102) is 
processed, the allomorph class (alio) is used as 
an auxiliary identifier (alio) . 

The method as claimed in one of claims 4 to 8, 
characterized in that the or a confirmation 
message (BN1 ' ) generated for the service computer 
(24) when the interface program (100) is being 
processed contains the auxiliary identifier (alio) 
and/or the class identifier (moC) and/or the 
origin identifier (oC) . 

The method as claimed in one of the preceding 
claims, characterized in that the network element 
is a switching office (16) , a cross-connector or a 
concentrator unit . 

The method as claimed in one of the preceding 
claims, characterized in that the tele- 
communications network (12) is a fixed network, a 
mobile radio network or a network with a fixed 
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network component and a mobile radio network 
component . 
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12 . The method as claimed in one of the preceding 

claims, characterized in that the interface 
program (100) carries out further interface 
functions between the service computer (24) and 
5 the application programs (102, 104), 

preferably an event control for defining the 
processing sequence of the maintenance messages 
(WN1 to WN3) and/or an adaptation of the messages 
(WN1 to WN3) coming from the service computer (24) 

10 to a protocol for transmitting messages within the 

control computer (16) , and/or an adaptation of the 
confirmation messages (BN1, BN2) coming from the 
application programs (102, 104) to a predefined 
protocol for transmitting messages between the 

15 service computer (24) and control computer (16) . 

13 . The method as claimed in one of the preceding 

claims, characterized in that a first application 
program (102) is used for subscriber 

2 0 administration, 

and/or a second application program is used for 
administering connecting lines to other switching 
devices , 

and/or a third application program is used for 
25 performing maintenance on the switching devices, 

and/or a fourth application program (104) is used 
for measuring the traffic on the switched links 
(18) . 

30 14. The method as claimed in claim 13, characterized 
in that the application objects (a2, a3) of the 
first application program (102) contain the 
subscriber data, preferably the call number and/or 
the useable telecommunications services, for one 

35 subscriber (Tln2, Tln3) in each case. 



15. The method as claimed in one of the preceding 
claims, characterized in that the maintenance 
messages (WN1 to WN3) contain a name identifier 



(mol) for the name of the application object (a2, 
a3) to which the maintenance message (WN1 to WN3) 
relates . 
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16. A network element (16) for operating a tele- 
communications network (10, 12), characterized in 
that it has a memory for storing instructions 
during whose processing the method according to 

5 one of the preceding claims is carried out. 

17. A telecommunications network (10, 12) 
characterized by a network element as claimed in 
claim 16. 
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Beschreibung 

Verfahren und Netzelement zum Betreiben eines Telekommunika- 
tionsnetzes 

Die Erfindung betrifft ein Verfahren zum Betreiben eines Te- 
lekommunikationsnetzes, kurz Tk-Netz, bei dem ein Netzelement 
an einem Netzknoten des Tk-Netzes von einem Steuerrechner ge- 
steuert wird. Das Netzelement ist beispielsweise eine Ver- 
mittlungsstelle zum Vermitteln von Verbindungen, ein soge- 
nannter Cross-Connector oder eine Konzentratoreinheit zum An- 
schluli mehrerer Teilnehmer an eine Verbindungsleitung. Im 
Steuerrechner sind neben dem Betriebssystem zum Betreiben des 
Steuerrechners mehrere Anwendungsprogramme gespeichert, bei 
deren Ausftihren Anwendungsob j ekte bearbeitet werden. Zu den 
Anwendungsobjekten gehoren Daten mit einer vorgegebenen Da- 
tenstruktur sowie vorzugsweise auch vorgegebene Verfahren zum 
Bearbeiten der Daten. Die Datenstruktur und die Verfahren 
sind abhangig von einer auch beim Erzeugen des jeweiligen An- 
wendungsob j ektes anzugebenden Klasse. Zwischen einem Be- 
dienrechner und einem Steuerrechner wird eine Verbindung auf- 
gebaut, uber die der Steuerrechner mittels Wartungsnach- 
richten gewartet wird. 

Derartige Verfahren werden zum Ftihren des Tk-Netzes einge- 
setzt, wenn zum Beispiel als Netzelement eine neue Vermitt- 
lungseinrichtung in Betrieb genommen wird oder wenn spater 
Teilnehmerdaten in der Vermittlungseinrichtung geandert wer- 
den mtissen, wie es beim Anschluft neuer Teilnehmer oder beim 
Umzug eines bisherigen Teilnehmers der Fall ist. Leistungsfa- 
hige Verfahren zum Ftihren des Tk-Netzes entstehen, wenn soge- 
nannte offene Systeme verwendet werden, bei deren Programmie- 
rung weltweit geltende Standards beachtet werden. Beispiels- 
weise betreffen Standards der ISO (International Standardisa- 
tion Organization) und der ITU -( International Telecommunica- 
tion Union) mit ihrem Organ ITU-T, frtiher CCITT (Internatio- 
nal Telegraph and Telephone Consultativ Committee) , den Auf- 
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bau solcher offenen Systeme. Zum Fiihren des Tk-Netzes soil 
ein separates Fiihrungsnetz verwendet werden. Die Schnittstel- 
len zwischen Bedienrechner und Vermittlungseinrichtung sind 
in Protokollen Ql, Q2 und Q3 standardisiert . 

Die Anwendungsobjekte sind als Objekte einer obj ektorientier- 
ten Sprache definiert, z.B. in der Sprache C++ oder CHILL, 
Werden die Anwendungsprogramme weiterentwickelt , so mulJ ge- 
wahrleistet werden, dafi das Fuhrungsnetz auch mit den neuen 
Anwendungsprogrammen fehlerfrei arbeitet. Das bedeutet insbe- 
sondere, dafi Anwendungsobjekte, die vom Bedienrechner als zu 
einer urspriinglichen Klasse gehorend angesehen werden, nicht 
ohne weiteres einer geanderten Ersatzklasse zugeordnet werden 
konnen. 

Dieses Problem wird im CCITT-Standard X.720 (01/92) - "Infor- 
mation Technology - Open Systems Interconnection - Structure 
of Management Information: Management Information Model" - im 
Abschnitt 5.2.1 angesprochen . Im Abschnitt 5.2.3 des Stan- 
dards X.72 0 werden zwei Methoden zum Losen des Problems vor- 
gegeben. Bei der ersten Methode wird auf der Seite des Anwen- 
dungsprogramms eine Programmiertechnik verwendet, die Allo- 
morphie berucksichtigt . Allomorphie ist die Fahigkeit eines 
bestimmten Anwendungsob j ektes der Ersatzklasse so gefuhrt zu 
werden, als ware es ein Objekt der urspriinglichen Klasse, 
wenn diese Fahigkeit durch Mafinahmen auf der Seite des Anwen- 
dungsprogramms entsteht. Die andere Methode besteht darin, 
dalJ auf der Seite des Bedienrechners MaJinahmen getroffen wer- 
den, welche auch bei einer Weiterentwicklung des Anwendungs- 
programms ein Zusammenarbeiten zwischen Bedienrechner und An- 
wendungsprogramm ermoglichen. 

Es ist Aufgabe der Erfindung zum Betreiben eines Telekommuni- 
kationsnetzes ein einfaches Verfahren anzugeben, bei dem Al- 
lomorphie berucksichtigt wird. 
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Diese Aufgabe wird durch ein Verfahren mit den Merkmalen des 
Patentanspruchs 1 gelost. Weiterbildungen sind in den Unter- 
anspriichen angegeben . 

5 Beim erf indungsgemafien Verfahren wird aus den Wartungsnach- 
richten beim Abarbeiten eines fiir mehrere Anwendungsprogramme 
genutzten Schnittstellenprogramms jeweils ein Klassenkennzei- 
chen ermittelt, in welchem die Klasse angegeben ist, auf die 
sich die Wartungsnachricht bezieht. Das Klassenkennzeichen in 

10 der Wartungsnachricht gibt die im Bedienrechner bekannte 

Klasse eines zu bearbeitenden Anwendungsobjektes an. Durch 
die Weiterentwicklung kommt es vor, dafl die im Bedienrechner 
bekannte Klasse von der tatsachlichen Klasse des Anwendungs- 
objekts abweicht. Beim Abarbeiten des Schnittstellenprogramms 

15 wird an Hand des Klassenkennzeichens ein Ersatzkennzeichen 
ermittelt, welches eine Ersatzklasse angibt, der das Anwen- 
dungsobjekt im Netzelement zugeordnet ist. Das Ersatzkennzei- 
chen wird in eine geanderte Wartungsnachricht auf genommen , 
Beim Bearbeiten der geanderten Wartungsnachricht durch ein 

2 0 Anwendungsprogramm wird das Anwendungsob j ekt dann als zur Er- 
satzklasse gehorend bearbeitet. Dies ist moglich, weil das 
Anwendungsob j ekt allomorph zu der im Bedienrechner bekannten 
Klasse ist, die in der ungeanderten Wartungsnachricht vom Be- 
dienrechner fiir das Anwendungsob j ekt vorausgesetzt worden 

25 ist. 

Das Schnittstellenprogramm ubernimmt zentral fiir mehrere An- 
wendungsprogramme die Zuordnung der Ersatzkennzeichen zu den 
Klassenkennzeichen. Beim erf indungsgemaflen Verfahren mufl die- 

30 ser Schritt nicht in jedem Anwendungsprogramm sondern nur 
einmal im Schnittstellenprogramm programmiert werden. Bei 
mehreren hundert Anwendungsprogrammen je Steuerrechner ver- 
ringert sich dadurch der Programmier-, Wartungs- und Dokumen- 
tationsaufwand erheblich. Die Anwendungsprogamme werden von 

35 zusatzlichen Schritten f reigehalten, die beim Berucksichtigen 
von Allomorphie notwendig sind, weil diese Schritte zentral 
im vorgelagerten Schnittstellenprogramm durchgefuhrt werden. 
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Ein Teil der zusatzlichen Schritte wird auch in nachgelager- 
ten Datenbanken durchgef iihrt, welche von den Anwendungspro- 
grammen genutzt werden. 

5 Das Ausfuhren der Zuordnung von Ersatzkennzeichen und Hilfs- 
kennzeichen in einem zentralen Schnittstellenprogramm ist 
moglich, weil Allomorphie beim erf indungsgemaflen Verfahren 
auf Klassenebene definiert ist. Eine derartige Definition ist 
im Standard X.72 0 nicht erwahnt aber dennoch standardgerecht . 

10 Allomorphie auf Klassenebene bedeutet, dali alle Objekte der 
Ersatzklasse so gefiihrt werden konnen, als waren sie Objekte 
der ursprunglichen Klasse. Durch eine auf alle Objekte der 
Ersatzklasse bezogene Definition von Allomorphie entstehen 
dann keine Nachteile, wenn vorgegebene Programmierregeln be- 

15 achtet werden. Beispiele fiir solche Programmierregeln werden 
unten im Zusammenhang mit den Ausf uhrungsbeispielen erlau- 
tert . 

Das erf indungsgemafie Verfahren ermoglicht es, die Vorgaben 
20 des Standards X.720 auf eine einfache Art und Weise einzuhal- 
ten. Die Anwendungsprogramme im Steuerrechner konnen mit ei- 
nem geringen Mehraufwand weiterentwickelt werden, wobei immer 
sichergestellt bleibt, daJ5 auch bei unverandert gebliebenen 
Programmen im Bedienrechner keine Fehler beim Betreiben des 
2 5 Fiihrungsnetzes auftreten. 

In einer Weiterbildung wird im Schnittstellenprogramm eine 
Tabelle verwendet, mit der dem Klassenkennzeichen die Ersatz- 
kennzeichen zugeordnet werden. Die Tabelle ist im Speicher 

30 des Steuerrechners gespeichert. Ein Eintrag der Tabelle wird 
gelesen, indem eine dem Klassenkennzeichen zugeordnete Spei- 
cherzelle gelesen wird, die das zum Klassenkennzeichen geho- 
rende Ersatzkennzeichen enthalt. Das Ermitteln des Ersatz- 
kennzeichens benotigt so nur einen einzigen Lesezugriff auf 

35 den Speicher. Andern sich durch Weiterentwicklungen der An- 
wendungsprogramme die Ersatzkennzeichen, so mussen nur die 
Speicherinhalte neu programmiert werden. Das bedeutet, dafl 
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der Inhalt der Tabelle leicht ausgetauscht oder erweitert 
werden kann, 

Wird in einer anderen Weiterbildung durch das Anwendungspro- 
gramm nach dem Bearbeiten der geanderten Wartungsnachricht 
eine Bestatigungsnachricht erzeugt, in der die beim Erzeugen 
des zu bearbeitenden Anwendungsobj ektes angegebene Klasse als 
Klassenzeichen angegeben ist, so kann die Bestatigungsnach- 
richt vom Schnittstellenprogramm nachfolgend auf einfache Art 
weiter bearbeitet werden. Beispielsweise kann beim Abarbeiten 
des Schnittstellenprogramms an Hand des Klassenkennzeichens 
festgestellt werden, welche Daten aus der Bestatigungsnach- 
richt zu entfernen sind. Dazu wird die im Schnittstellenpro- 
gramm verwendete Tabelle so erweitert, daJi zu jedem Klassen- 
kennzeicheri auch Eintragungen zu den erlaubten Daten gehoren. 
Das Schnittstellenprogramm erzeugt dann aus der Bestatigungs- 
nachricht eine neue Bestatigungsnachricht, die nur solche Da- 
ten eines Anwendungsobj ekts der Klasse enthalt, auf die sich 
die Bestatigungsnachricht bezieht. 

Die beim Erzeugen des zu bearbeitenden Anwendungsobj ektes an- 
gegebene Klasse wird in einer Weiterbildung als Ursprungs- 
klasse in den Daten des zu bearbeitenden Anwendungsobj ekts 
gespeichert. Beim Abarbeiten des Anwendungsprogramms wird die 
Ursprungsklasse dann als Klassenkennzeichen verwendet. Durch 
diese Vorgehensweise ist die Ursprungsklasse auf einfache Art 
und Weise verfugbar. 

Enthalt die Bestatigungsnachricht in einer anderen Weiterbil- 
dung auch ein Hilf skennzeichen, in welchem mindestens eine 
Klasse bezeichnet ist, die im Bedienrechner und/oder in min- 
destens einem anderen Bedienrechner als die Klasse bekannt 
ist, zu der das zu bearbeitende Anwendungsobj ekt gehort, so 
kann spater das Programm im Bedienrechner an Hand des Hilfs- 
kennzeichens ermitteln, wie die empfangene Bestatigungsnach- 
richt zu bearbeiten ist. Dies ist insbesondere dann von Be- 
deutung, wenn die im Klassenkennzeichen der vom Bedienrechner 
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empfangenen Bestatigungsnachricht angegebene Klasse im Be- 
dienrechner noch nicht bekannt ist. Der Bedienrechner be- 
stimmt die Klasse, auf die sich die Bestatigungsnachricht be- 
zieht dann an Hand der im Hilf skennzeichen angegebenen Klasse 
bzw. Klassen. Das Hilf skennzeichen enthalt, mit anderen Wor- 
ten ausgedriickt, die Klassen, zu denen das Anwendungsobj ekt 
allomorph ist. Enthalt die Bestatigungsnachricht neben dem 
Klassenkennzeichen auch ein Ursprungskennzeichen, in dem die 
Ursprungsklasse angegeben ist, so lassen sich die Vorgaben 
des Protokolls fur den Nachrichtenaustausch im Steuerrechner 
und auch fur das Protokoll fur den Nachrichtenaustausch zwi- 
schen Bedienrechner und Steuerrechner erfiillen. 

In einer anderen Weiterbildung wird mindestens eine im Be- 
dienrechner und/oder in mindestens einem anderen Bedienrech- 
ner fur das Anwendungsobj ekt bekannte Klasse als Allomorph- 
klasse in den Daten des Anwendungsobj ekts gespeichert. Beim 
Abarbeiten des Anwendungsprogramms wird dann die Allomorph- 
klasse als Hilf skennzeichen verwendet. Durch diese Maflnahme 
entsteht eine ubersichtliche Datenstruktur , bei der die An- 
wendungsobj ekte ihre Allomorphklassen selbst verwalten. Im 
Schnittstellenprogramm und im Anwendungsprogramm miissen keine 
zusatzlichen Malinahmen hinsichtlich der Allomorphklasse ge- 
troffen werden. 

In einer anderen Weiterbildung ist das Schnittstellenprogramm 
auch fur andere Schnittstellenf unktionen zustandig. Bei- 
spielsweise fur die Ereignissteuerung zum Festlegen der Bear- 
beitungsreihenf olge der Wartungsnachrichten oder fur Proto- 
kollanpassungen dieser Nachrichten, englisch als "basic enco- 
ding" bezeichnet. Durch diese Mafinahme gibt es auf dem Steu- 
errechner nur ein einziges Schnittstellenprogramm, das ein- 
heitlich programmiert und gewartet wird, 

Im folgenden werden Ausf uhrungsbeispiele der Erfindung an 
Hand der Zeichnungen erlautert. Darin zeigen: 
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einen Teil eines Fiihrungsnetzes zum Fuhren eines 
TelekommunikationsnetzeS/ 

die Weiterentwicklung einer ursprunglichen Klasse A 
zu einer erweiterten Klasse A' , deren Objekte beim 
Betreiben des Fiihrungsnetzes wie Objekte der alten 
Klasse A gefiihrt werden konnen, 

das Bearbeiten von Nachrichten im Steuerrechner ei- 
ner Vermittlungseinheit nach der Weiterentwicklung, 
wobei ein Objekt gefiihrt wird, das vor der Weiter- 
entwicklung erzeugt worden ist, 

das Bearbeiten von Nachrichten im Steuerrechner 
nach der Weiterentwicklung, wobei ein Objekt ge- 
fiihrt wird, das nach der Weiterentwicklung erzeugt 
worden ist, 

die Namensbindung der Klassen A und A 1 sowie ein 
Zugriff auf Objekte der beiden Klassen mittels ei- 
ner Filterfunktion. 

Figur 1 zeigt einen Teil eines Fiihrungsnetzes 10 zum Fuhren 
eines TelekommunikationsnetzeS 12, kurz Tk-Netz 12 genannt . 
Das Tk-Netz 12 enthalt eine Vielzahl von Vermittlungsstellen, 
von denen in Figur 1 die Vermittlungsstellen 14 und 16 darge- 
stellt sind. Zum Tk-Netz 12 gehoren weiterhin Verbindungslei- 
tungen zwischen den Vermittlungsstellen, von denen in Figur 1 
eine Verbindungsleitung 18 zwischen der Vermittlungsstelle 14 
und der Vermittlungsstelle 16 dargestellt ist. Das Tk-Netz 12 
verbindet die Teilnehmer des Tk-Netzes 12, beispielsweise ei- 
nen an die Vermittlungsstelle 14 angeschlossenen Teilnehmer 
Tlnl und einen an die Vermittlungsstelle 16 angeschlossenen 
Teilnehmer Tln2 . 

Das Fuhrungsnetz 10 enthalt eigene Ubertragungsstrecken 20 
und 22, die zu einem Bedienrechner 24 fuhren. Die Ubertra- 



Figur 1 



Figur 2 



Figur 3 



Figur 4 



Figur 5 
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gungsstrecke 20 Obertragt Wartungsnachrichten vom Bedienrech- 
ner 24 zur Vermittlungsstelle 14, urn beispielsweise in der 
Vermittlungsstelle 14 Teilnehmerdaten des Teilnehmers Tlnl zu 
andern. Die Vermittlungsstelle 14 sendet ihrerseits Bestati- 
5 gungsnachrichten an den Bedienrechner 24, um die ordnungsge- 
mafle Bearbeitung der empfangenen Wartungsnachricht zu signa- 
lisieren. Die Ubertragungsstrecke 22 dient zur bidirektiona- 
len Datenubertragung zwischen Bedienrechner 24 und Vermitt- 
lungsstelle 16, 

10 

Die Wartungsnachrichten werden in der Vermittlungsstelle 14 
von einem Steuerrechner 34 und in der Vermittlungsstelle 16 
von einem Steuerrechner 36 bearbeitet. Die Datenstrukturen, 
auf die sich die Wartungsnachrichten beziehen, gehoren im Be- 

15 dienrechner 24 und in der Vermittlungsstelle 14 derselben 

Klasse A an. Die Vermittlungsstelle 16 enthalt dagegen Daten- 
strukturen einer Klasse A 1 , die gegenuber der im Bedienrech- 
ner 24 vorausgesetzten Klasse A weiterentwickelt worden ist. 
Der fehlerfreie Betrieb des Fiihrungsnetzes 10 wird beziigli.ch 

20 der Vermittlungsstelle 16 dadurch gewahrleistet , dali beim 

Weiterentwickeln der Klasse A zur Klasse A 1 Allomorphie be- 
rucksichtigt worden ist. Was Allomorphie in diesem Zusammen- 
hang bedeutet, wird unten an Hand der Figur 2 erlautert. 

25 Beim in Figur 1 dargestellten Ausf uhrungsbeispiel wird in der 
Vermittlungsstelle 14 die Klasse A verwendet, die beispiels- 
weise die Datenstruktur fur Teilnehmerdaten festlegt, z.B. 
die Rufnummer und die nutzbaren Dienste des Tk-Netzes 12. 
Teilnehmerdaten des Teilnehmers Tlnl sind in einem Objekt al 

30 gemali der durch die Klasse A vorgegebenen Datenstruktur in 
einem Speicher 38 des Steuerrechners 34 gespeichert. Die 
Klasse A ist auch im Bedienrechner 24 bekannt, angedeutet 
durch den Buchstaben A in einem Speicher 4 0 des Bedienrech- 
ners 24. 

35 

In der Vermittlungsstelle 16 wurde die Klasse A zur Klasse A f 
weiterentwickelt. Ein Objekt a2 enthalt beispielsweise die 
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Teilnehmerdaten des Teilnehmers Tln2. Das Objekt a2 wurde 
erstmalig im Speicher 42 gespeichert, bevor die Klasse A zur 
Klasse A f weiterentwickelt worden ist. Bei der Weiterent- 
wicklung wurde das urspriingliche Objekt a2 aber umgewandelt, 
5 und zwar in ein erweitertes Objekt a2 der Klasse A T , indem 
ein Datenfeld erganzt worden ist, Ein Objekt a3 im Speicher 
42 gehort zur Klasse A' und enthalt die Teilnehmerdaten eines 
Teilnehmers Tln3, dessen Anschlufi erst nach der Weiterent- 
wicklung in der Vermittlungsstelle 16 eingerichtet worden 

10 ist. Obwohl die Programme im Bedienrechner 24 nur Objekte der 
Klasse A untersttitzen, konnen die zur Klasse A ? gehorenden 
Objekte a2 und a3 vom Bedienrechner 24 aus wie Objekte der 
Klasse A abgefragt, geandert oder neu eingerichtet werden. 
Die Erweiterungen der Klasse A f im Vergleich zur Klasse A 

15 konnen vom Bedienrechner 24 allerdings erst dann bearbeitet 
werden, wenn die Programme im Bedienrechner 24 zu einem spa- 
teren Zeitpunkt so geandert werden, dali auch die Klasse A f im 
Bedienrechner 24 bekannt ist . 

20 Figur 2 zeigt die Klassen A und A' sowie das urspriingliche 

Objekt a2 und das Objekt a3. An Hand der Figur 2 wird im fol- 
genden erlautert, was die Bezeichnung "allomorph zu" bedeu- 
tet. Die Klasse A 1 unterscheidet sich von der Klasse A nur 
durch ein zusatzliches Datenfeld 50. Die Datenstruktur der 

25 Klasse A wurde also um das Datenfeld 50 erweitert, urn eine 
weitere Eigenschaft der Teilnehmer Tln2, Tln3 beim Betrieb 
der Vermittlungsstelle 16 beriicksichtigen zu konnen, z.B. ob 
der Teilnehmer Tln2, Tln3 uber einen Lichtwellenleiter oder. 
uber einen Kupferleiter an die Vermittlungsstelle 16 ange- 

30 schlossen ist. Die Klasse A f wird deshalb im folgenden auch 

als erweiterte Klasse A' bezeichnet. Ein Datenfeld 50' im Ob- 
jekt a3 enthalt als Datum einen Wert, der angibt, dafi der 
Teilnehmer Tln3 mittels eines Lichtwellenleiters an die Ver- 
mittlungsstelle 16 angeschlossen ist. Das Objekt a3 wird all- 

35 gemein als erweitertes Objekt a3 bezeichnet. 
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Die Klasse, die beim Erzeugen eines Objektes angegeben wird, 
wird als ursprungliche Klasse dieses Objekts bezeichnet. Das 
Objekt a2 hatte als ursprungliche Klasse die Klasse A, ange- 
deutet durch einen Pfeil 52. Das erweiterte Objekt a3 hat da- 
gegen als ursprungliche Klasse die erweiterte Klasse A f , an- 
gedeutet durch einen Pfeil 54. 

Eine erste Moglichkeit zum Festlegen der Datenstruktur der 
Klasse A besteht darin, die Klasse A ? aus der Klasse A mit- 
tels sogenannter Vererbung zu erzeugen, die in objektorien- 
tierten Programmiersprachen definiert ist. Solche Program- 
miersprachen sind z.B. die Sprachen C++ und CHILL. Bei einer 
Vererbung wird durch den Prograinmierer angegeben, daii die er- 
weiterte Klasse A' von der Klasse A samtliche Datenstrukturen 
und sogenannten Methoden zum Bearbeiten der Datenstrukturen 
ubernehmen soil. Weiterhin wird angegeben, dafi die Klasse A 1 
zusatzlich das Datenfeld 50 enthalt. Eine andere Moglichkeit 
zum Festlegen der Klasse A T besteht darin, diese Klasse neu 
zu definieren. In diesem Fall wird die Klasse A' so defi- 
niert, wie es bereits bei der Klasse A der Fall war. Zusatz- 
lich wird jedoch noch das Datenfeld 50 definiert. Die Bezie- 
hung der iibereinstimmenden Teile der Klasse A und der erwei- 
terten Klasse A' ist in Figur 2 mittels Strichlinien 56 dar- 
gestellt . 

In einem gedachten Obj ekt a3* sind aus dem Objekt a3 alle Da- 
tenfelder und alle Methoden zum Bearbeiten der Datenfelder 
enthalten, die auch beim Einrichten des Teilnehmers Tln3 vor 
der Weiterentwicklung erzeugt worden waren, als es zwar die 
Klasse A, aber noch nicht die Klasse A' gab. Im Objekt a3* 
fehlt deshalb ein dem Datenfeld 50 bzw. 50 1 entsprechendes 
Datenfeld. Dieser Sachverhalt wird durch Strichlinien 58 ver- 
deutlicht. Das Objekt a3* ist eine Anschauungshilf e zum Ab- 
grenzen der Begriffe "kompatibel zu" und "allomorph zu" . Ein 
Pfeil 60 verdeutlicht, dafi das Objekt a3* kompatibel zur 
Klasse A ist, weil es genau die Datenstrukturen hat, die in 
der Klasse A vorgegeben sind. Das erweiterte Objekt a3 ist 
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dagegen allomorph zur Klasse A, vgl . Pfeil 62. Das Objekt a3 
hat die allomorphe Klasse A. 

Allomorphie ist die Fahigkeit der Objekte der Klasse A' so 
5 gefiihrt zu werden, als waren sie Objekte ihrer allomorphen 
Klasse A, wenn diese Fahigkeit durch Mafinahmen auf der Seite 
des Anwendungsprogramms entsteht. Bei einer stufenweisen Er- 
weiterung kann es mehr als eine allomorphe Klasse geben, z.B. 
die allomorphe Klasse der letzten Erweiterung und die allo- 
10 morphe Klasse der vorletzten Erweiterung. 

Ein erweitertes Objekt hat nur dann eine allomorphe Klasse, 
wenn das erweiterte Objekt ohne die Erweiterungen zur allo- 
morphen Klasse kompatibel gemafi Standard X.720 Abschnitt 

15 5.2.2 ist. Insbesondere hat das erweiterte Objekt demnach al- 
le Attribute, Attributgruppen, Fuhrungsf unktionen und Besta- 
tigungsverf ahren, die auch in der allomorphen Klasse festge- 
legt sind. Durch das Beriicksichtigen der Allomorphie beim Er- 
weitern der Klasse A wird erreicht, dafl das Fuhrungsnetz 10 

20 auch nach der Erweiterung fehlerfrei arbeitet. 

Figur 3 zeigt das Bearbeiten von Nachrichten im Steuerrechner 
16 nach der Weiterentwicklung der Klasse A zur Klasse A', wo- 
bei das Objekt a2 geftihrt wird, das vor der Weiterentwicklung 

25 als zur Klasse A gehorend angelegt worden ist. Beim Weiter- 
entwickeln der Klasse A zur Klasse A' wurde Allomorphie be- 
rucksichtigt, so dafl Objekte der Klasse A f zur Klasse A allo- 
morph sind. AuBerdem wurden beim Weiterentwickeln alle Objek- 
te der Klasse A in Objekte der Klasse A 1 umgewandelt , indem 

30 Datenfelder und Methoden erganzt worden sind. 

Der Steuerrechner 16 enthalt ein Schnittstellenprogramm 100, 
das vom Bedienrechner 24 kommende Wartungsnachrichten, bei- 
spielsweise eine Wartungsnachricht WN1, bearbeitet und das 
35 Bestatigungsnachrichten, beispielsweise eine Bestatigungs- 

nachricht BN1 1 , an den Bedienrechner 24 sendet. Das Schnitt- 
stellenprogramm 100 ist die Schnittstelle zwischen dem Be- 
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dienrechner 24 und mehreren Anwendungsprogrammen im Steuer- 
rechner 16, von denen in Figur 3 zwei Anwendungsprogramme 102 
und 104 gezeigt sind. Das Anwendungsprogramm 102 dient zum 
Verwalten der zu den an die Vermittlungsstelle 16 angeschlos- 
5 senen Teilnehmern Tln2, Tln3 gehorenden Daten. Das Anwen- 
dungsprogramm 104 wird zur Verkehrsmessung verwendet. 

Die vom Bedienrechner kommende Wartungsnachricht WN1 wird 
beim Abarbeiten des Schnittstellenprogramms 100 an das Anwen- 
10 dungsprogramm 102 als geanderte Wartungsnachricht WN1 f wei- 
tergeleitet. Fur das Anwendungsprogramm 104 bestimmte War- 
tungsnachrichten werden dagegen beim Abarbeiten des Schnitt- 
stellenprogramms 100 an das Anwendungsprogramm 104 weiterge- 
leitet, vgl. Pfeil 106. 

15 

Nach dem Bearbeiten der Wartungsnachricht WN1 ' im Anwendungs- 
programm 102 erzeugt das Anwendungsprogramm 102 eine Bestati- 
gungsnachricht BN1 fur die Schnittstelle 100. Hat das Anwen- 
dungsprogramm 104 eine Wartungsnachricht bearbeitet, so sen- 
20 det es ebenfalls eine Bestatigungsnachricht an das Schnitt- 
stellenprogramm 100, vgl. Pfeil 108. 

Beim Bearbeiten der Wartungsnachricht WN1 1 arbeitet das An- 
wendungsprogramm 102 mit einem ebenfalls im Steuerrechner 36 

25 vorhandenen Datenbankprogramm 110 zusammen, mit dem Teilneh- 
merdaten im Speicher 42 gespeichert, verandert, geloscht oder 
gelesen werden. Das Anwendungsprogramm 102 sendet Anforderun- 
gen in Form von Nachrichten an das Datenkbankprogramm 110, 
beispielsweise die Nachricht Nl . Nach dem Ausfuhren der An- 

30 forderung in der Nachricht Nl sendet das Datenbankprogramm 

110 eine Ergebnisnachricht EN1 an das Anwendungsprogramm 102 
zuruck. Das Anwendungsprogramm 104 arbeitet mit einem eigenen 
Datenbankprogramm 112 zusammen, indem es Anf orderungen an das 
Datenbankprogramm 112 sendet, vgl. Pfeil 114, und indem es 

35 vom Datenbankprogramm 112 Ergebnisnachrichten empfangt und 
weiterbearbeitet, vgl. Pfeil 116. 
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Das Datenbankprogramm 110 benutzt fur die Objekte der ur- 
sprunglichen Klasse A und die Objekte der weiterentwickelten 
Klasse A 1 dasselbe Zugrif f sverf ahren . Dies ist moglich, weil 
Kombinationsklassen verwendet werden, in denen die Daten- 
5 strukturen und Methoden der urspriinglichen Klasse und der er- 
weiterten Klasse zusammengef uhrt sind. Eine Kombinations- 
klasse KA ist die Kombination der Klasse A und der Klasse A' . 
Samtliche Objekte im Speicher 42, welche die allomorphe Klas- 
se A als ursprungliche Klasse haben, werden mit der Weiter- 
10 entwicklung urn die zusatzlichen Datenfelder der erweiterten 
Klasse A erweitert. Die zusatzlichen Datenfelder werden mit 
vorgegebenen Werten belegt. 

Die Wartungsnachricht WN1 enthalt ein Klassenkennzeichen moC, 
15 das die Klasse A als die Klasse angibt, auf welche sich die 

Wartungsnachricht WN1 bezieht. Ein Ob j ektkennzeichen mol gibt 
das Objekt a2 an, auf das sich die Wartungsnachricht WN1 be- 
zieht. Die Wartungsnachricht WN1 wird vom Bedienrechner 24 
gesendet, urn die Teilnehmerdaten des Teilnehmers Tln2 zu er- 
20 fahren. Im Bedienrechner 24 ist lediglich bekannt, dafi diese 
Teilnehmerdaten in dem Objekt a2 enthalten sind, das im Steu- 
errechner 36 gespeichert ist. Die Wartungsnachricht WN1 ent- 
halt weitere nicht dargestellte Datenfelder. In einem dieser 
Datenfelder ist beispielsweise die auszuf uhrende Leseoperati- 
25 on festgelegt. 

Beim Bearbeiten der Wartungsnachricht WN1 im Schnittstellen- 
programm 100 wird die im Klassenkennzeichen moC angegebene 
Klasse A ermittelt. An Hand der so ermittelten Klasse A wird 
30 beim Abarbeiten des Schnittstellenprogramms 100 mittels einer 
Tabelle T die Klasse A f als Ersatzklasse ermittelt und in das 
Klassenkennzeichen moC der Wartungsnachricht WN1 eingetragen. 
Die Tabelle T ist in einem Speicher 122 des Steuerrechners 36 
gespeichert . 

35 

Die Wartungsnachricht WN1 1 betrifft mit dem Klassenkennzei- 
chen moC=A' die erweiterte Klasse A 1 . Der Wert des Objekt- 
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kennzeichens moI=a2 bleibt in der Wartungsnachricht WN1 ' un- 
verandert. Ein Kennzeichen alio in der Wartungsnachricht WN1 ' 
gibt alle Klassen an, die zur Klasse A 1 allomorph sind, d.h. 
im Ausfiihrungsbeispiel die Klasse A. Das Schnittstellenpro- 
5 grainm 100 entnimint diese Klassen ebenfalls der Tabelle T. Die 
anderen Daten der Wartungsnachricht WN1 werden in die War- 
tungsnachricht WN1 ' iibernommen. Beim Erzeugen der zur War- 
tungsnachricht WN1 gehorenden Wartungsnachricht WN1 1 fuhrt 
das Schnittstellenprogramm 100 auch eine Protokollanpassung 
10 von einem Obertragungsprotokoll auf der Obertragungsstrecke 

22 in ein Nachrichtenprotokoll durch, das innerhalb des Steu- 
errechners 36 verwendet wird. 

Die beim Bearbeiten der Wartungsnachricht WN1 ' durch das An- 
15 wendungsprogramm 102 erzeugte Nachricht Nl enthalt einen Be- 
fehl Bl, der angibt, dali Daten gelesen werden sollen. Als Pa- 
rameter des Befehls Bl enthalt die Nachricht Nl die Klasse 
A' , zu der die zu lesenden Daten gehoren, sowie das Objekt 
a2, dessen Daten gelesen werden sollen. Das Anwendungspro- 
20 gramm 102 bearbeitet ausschlielilich Nachrichten, die sich auf 
Objekte der Klasse A' beziehen. Bezuglich der Klasse A sind 
im Anwendungsprogramm 102 keine weiteren MaBnahmen getroffen. 

Das Datenbankprogramm 110 greift beim Bearbeiten der Nach- 
25 richt Nl auf den Speicher 42 zu, urn die Daten des Teilnehmers 
Tln2 zu lesen, die im Objekt a2 gespeichert sind. Das Objekt 
a2 enthalt auflerdem ein Ursprungskennzeichen oC, in dem die 
Klasse A angegeben ist, die beim Erzeugen des Objekts a2 an- 
gegeben worden ist. Das Datenbankprogramm 110 liest die mit 
30 dem Befehl Bl angef orderten Daten im Objekt a2 und tragt die- 
se Daten in die Ergebnisnachricht EN1 ein. In der Ergebnis- 
nachricht EN1 ist auJierdem mittels eines Antwortkennzeichens 
AB1 vermerkt, dafi die Ergebnisnachricht EN1 das Ergebnis ent- 
halt, das beim Bearbeiten des Befehls Bl erzeugt worden ist. 
35 Weiterhin ist in der Ergebnisnachricht EN1 die Klasse A f als 
die Klasse angegeben, welche von der Ergebnisnachricht EN1 
betroffen ist. Das Ursprungskennzeichen oC=A wird ebenfalls 
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vom Datenbankprogramm 110 in der Ergebnisnachricht EN1 an das 
Anwendungsprogramm 102 ubermittelt. 

Beim Abarbeiten des Anwendungsprogramms 102 wird vorausge- 
5 setzt, dali sich alle zu bearbeiteten Nachrichten auf die 

Klasse A 1 und nicht auf die Klasse A beziehen. Durch das An- 
wendungsprogramm 102 wird der Wert des Ursprungskennzeichens 
oC=A als Wert des Klassenkennzeichens moC in der Bestati- 
gungsnachricht BN1 ubernommen. Fur diese Wertzuweisung ist es 

10 nicht erf orderlich, dali das Anwendungsprogramm 102 Objekte 
der Klasse A bearbeiten kann. AuBerdem enthalt die Bestati- 
gungsnachricht BN1 das Ursprungskennzeichen oC=A und die ab- 
gefragten Teilnehmerdaten des Teilnehmers Tln2 . Das Schnitt- 
stellenprogramm 100 braucht sich aufgrund dieser Vorgehens- 

15 weise das Klassenkennzeichen der Wartungsnachricht WN1 nicht 
zu merken. 

Die Bestatigungsnachricht BN1 wird vom Schnittstellenprogramm 
100 bearbeitet und als Bestatigungsnachricht BN1 1 gemaJS dem 

20 Ubertragungsprotokoll auf der Obertragungsstrecke 22 an den 
Bedienrechner 24 gesendet. An Hand der Tabelle T ermittelt 
das Schnittstellenprogramm 100, welche Datenfelder in der 
Nachricht BN1 nicht in Objekten der Klasse A enthalten sind. 
Diese Datenfelder werden nicht in die Bestatigungsnachricht 

25 BN1 1 ubernommen. 

Der Bedienrechner 24 empfangt die Bestatigungsnachricht BN1 ' 
und kann sie wie eine Nachricht bearbeiten, die sich auf ein 
Objekt der Klasse A bezieht. Objekte der Klasse A' im Steuer- 
30 rechner 36 werden vom Bedienrechner 24 aus so gefiihrt, als 
waren sie Objekte der Klasse A, Die Weiterentwicklung im 
Steuerrechner 36 schrankt die Betriebsmerkmale des Bedien- 
rechners 24 somit nicht ein. 

35 Figur 4 zeigt das Bearbeiten von Nachrichten im Steuerrechner 
16 nach der Weiterentwicklung der Klasse A zur Klasse A f , wo- 
bei das Objekt a3 gefiihrt wird, das erst nach der Weiterent- 
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wicklung erzeugt wird. Durch die Eingaben einer Bedienperson 
in den Bedienrechner 24 wird im Bedienrechner 2 4 eine War- 
tungsnachricht WN2 erzeugt, welche die Aufgabe hat, im Steu- 
errechner 16 das Objekt a3 flir die Teilnehmerdaten des Teil- 
5 nehmers Tln3 zu erzeugen. Die Wartungsnachricht WN2 enthalt 
deshalb in einem Befehlsfeld eine Codierung fiir den Befehl 
"Erzeuge". Das Klassenkennzeichen moC in der Wartungsnach- 
richt WN2 kennzeichnet die Klasse A als die Klasse, auf die 
sich die Wartungsnachricht WN2 bezieht. Das Objektkennzeichen 
10 mol der Wartungsnachricht WN2 kennzeichnet das Objekt a3, das 
durch die Wartungsnachricht WN2 erzeugt werden soil. Die War- 
tungsnachricht WN2 enthalt auflerdem noch weitere nicht darge- 
stellte Daten. 

15 Das Schnittstellenprogramm 100 bearbeitet die Wartungsnach- 
richt WN2 ebenso wie oben fiir die Wartungsnachricht WN1 er- 
lautert. Beim Bearbeiten der Wartungsnachricht WN2 wird wie- 
derum die im Speicher 122 gespeicherte Tabelle T verwendet, 
urn fiir die im Klassenkennzeichen moC der Wartungsnachricht 

20 WN2 angegebene Klasse A die Ersatzklasse A 1 zu ermitteln und 
als Klassenkennzeichen moC der Wartungsnachricht WN2 f zu ver- 
wenden. Das Objektkennzeichen moI=a3 hat in der Wartungsnach- 
richt WN2 1 den gleichen Wert, wie in der Wartungsnachricht 
WN2 . Auch die verbleibenden Daten werden aus der Wartungs- 

25 nachricht WN2 beim Ausfuhren des Schnittstellenprogramms 100 
in die Wartungsnachricht WN2 ' ubernommen. Zusatzlich wird im 
Kennzeichen alio der Wartungsnachricht WN2 ' vermerkt, dali die 
Klasse A die Klasse ist, zu der die Klasse A 1 allomorph ist. 
Die so erzeugte Wartungsnachricht WN2 ' wird vom Schnittstel- 

30 lenprogramm 100 gemafl dem Protokoll im Steuerrechner 36 an 
das Anwendungsprogramm 102 gesendet. 

Das Anwendungsprogramm 102 sendet beim Bearbeiten der War- 
tungsnachricht WN2 f eine Nachricht N2 an das Datenbankpro- 
35 gramm 110, urn das Objekt a3 im Speicher 42 anlegen zu lassen. 
Die Nachricht N2 enthalt verschlusselt den Befehl "Erzeuge", 
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die erweiterte Klasse A' sowie den Namen des anzulegenden Ob- 
jekts a3. 

Beim Bearbeiten der Nachricht N2 mittels des Datenbankpro- 
5 gramms 110 wird im Speicher 42 das Objekt a3 erzeugt, indem 
diesem Objekt bestimmte Speicher zellen zugewiesen werden, die 
mit Anfangswerten belegt werden. Im Ursprungskennzeichen oC 
des Objekts a3 wird die Klasse A 1 vermerkt, weil diese Klasse 
beim Erzeugen des Objektes a3 f angegeben wurde . Ein Kennzei- 
10 chen alio im Objekt a3 weist auf die Klasse A hin, weil das 
Objekt a3 zu der Klasse A allomorph ist. 

Das Datenbankprogramm 110 erzeugt eine Ergebnisnachricht EN2, 
urn das Erzeugen des Objekts a3 zu bestatigen. Die Ergebnis- 

15 nachricht EN2 enthalt ein Antwortkennzeichen AB2, das angibt, 
dai3 die Ergebnisnachricht EN2 beim Bearbeiten eines Befehls 
"Erzeuge" entstanden ist. Weiterhin enthalt die Ergebnisnach- 
richt EN2 ein Kennzeichen, das auf die Klasse A' hinweist, 
das Ursprungskennzeichen oC=A' , das Kennzeichen allo=A sowie 

20 weitere nicht dargestellte Daten des Objekts a3. 

Die Ergebnisnachricht EN2 wird vom Anwendungsprogramm 102 be- 
arbeitet, wobei eine Bestatigungsnachricht BN2 erzeugt wird. 
In der Bestatigungsnachricht BN2 wird als Wert des Klassen- 
25 zeichens moC der Wert des Ursprungskennzeichens oC=A f verwen- 
det. Die anderen Daten der Ergebnisnachricht EN2 werden in 
die Bestatigungsnachricht BN2 ubernommen. 

Beim Abarbeiten des Schnittstellenprogramms 100 wird nach dem 
30 Empfang der Bestatigungsnachricht BN2 eine Bestatigungsnach- 
richt BN2 1 gemafl dem auf der Ubertragungsstrecke 22 verwende- 
ten Ubertragungsprotokoll erzeugt. Die Bestatigungsnachricht 
BN2 ' enthalt alle Daten der Bestatigungsnachricht BN2 , weil 
das Schnittstellenprogramm 100 an Hand der Tabelle T fest- 
35 stellt, daB keine Datenfelder entfernt werden miissen, wenn 
die Bestatigungsnachricht BN2 als Klassenkennzeichen die 
Klasse A 1 hat. 
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Beim Bearbeiten der Bestatigungsnachricht BN2 ' im Bedienrech- 
ner 24 wird an Hand des Kennzeichens alio f estgestellt , daB 
die Bestatigungsnachricht BN2 1 Daten eines Objekts der Klasse 
5 A betrifft bzw. dafi die Bestatigungsnachricht BN2 ' so behan- 
delt werden kann, als wiirde sie Daten eines Objektes der 
Klasse A enthalten. Obwohl das Programm im Bedienrechner 24 
nach der Weiterentwicklung im Steuerrechner 36 nicht veran- 
dert worden ist, konnen Objekte der Klasse A' im Steuerrech- 
10 ner 36 vom Steuerrechner 24 aus so gefiihrt werden, als waren 
sie Objekte der Klasse A. Solange im Bedienrechner A nur die 
Klasse A bekannt ist, werden in der Bestatigungsnachricht 
BN2 1 auch nur die in Objekten der Klasse A enthaltenen Daten 
bearbeitet . 

15 

Aufgrund des an Hand der Figuren 3 und 4 erlauterten Verfah- 
rens ist es auch moglich, Klassen zu unterstiitzen, die zu 
mehreren Klassen allomorph sind. Wird z.B. die Klasse A' zu 
einer Klasse A f ' weiterentwickelt , so konnen Objekte zu den 

20 Klassen A' und A allomorph sein. Der Steuerrechner 36 kann 

dann von Bedienrechnern 24 ausgefiihrt werden, bei deren Pro- 
grammierung mindestens eine der Klassen A, A f oder A T ' be- 
kannt war. Auf eine Untersttitzung der Klasse A kann verzich- 
tet werden, sobald alle Bedienrechner zumindest die Klasse A' 

2 5 kennen. 

Das an Hand der Figuren 3 und 4 erlauterte Verfahren wird bei 
Wartungsnachrichten zum Erzeugen und bei Wartungsnachrichten 
zum Lesen von Objekten angewendet. AuBerdem konnen mit diesem 
30 Verfahren Daten in Objekten verandert sowie Objekte geloscht 
werden. Damit diese Verfahren fehlerfrei arbeiten, muft der 
Bedienrechner 24 fahig sein: 

Die Bestatigungsnachrichten BN den zugehorigen Wartungs- 
35 nachrichten WN zuzuordnen, 
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das Kennzeichen alio in den Bestatigungsnachrichten BN zu 
lesen und auszuwerten, 

unbekannte Namensbindungen (vgl. Erlauterungen zu Fig. 5) 
5 zu ubergehen und unbekannte Kennzeichenwerte und Parame- 

ter zu ubergehen, 

falls im Bedienrechner eine Datenbank vorhanden ist die 
Ursprungsklasse eines Objekts zu speichern, 

10 

unbekannte wahlfreie Werte zu ubergehen, und 

unbekannte Werte vom Datentyp "enumerated" zu ubergehen. 

15 Mit anderen Worten muli der Bedienrechner 24 so programmiert 

sein, dafi von ihm aus Objekte in einen Steuerrechner mit gro- 
iierem Wissen geftihrt werden konnen. 

Das Schnittstellenprogramm 100 hat folgende Merkmale: 

Beim Erweitern einer Klasse ist es erf orderlich, die er- 
weiterte Klasse in die Tabelle T aufzunehmen, das be- 
deutet, daii flir jede erweiterte Klasse die Klassen ge- 
speichert werden mussen, zu denen die erweiterte Klasse 
allomorph ist. 

Die Namensbindungen, welche von der erweiterten Klasse 
betroffen werden, mussen in der Tabelle T gespeichert 
werden. 

30 

Das Schnittstellenprogramm 100 soil aus den vom Anwen- 
dungsprogramm 102 kommenden Bestatigungsnachrichten BN 
die Daten entfernen, die nicht zur kompatiblen Klasse ge- 
horen, falls die an den Bedienrechner 24 gesendete Be- 
35 statigungsnachricht BN die nicht erweiterte Klasse be- 

trif ft . 



20 
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Das Schnittstellenprogramm 100 mufl Filterbef ehle bearbei- 
ten konnen. Dies wird unten an Hand der Figur 5 noch ge- 
nauer erlautert. 



5 Das Anwendungsprogramm 102 erfiillt die folgenden Anforderun- 
gen: 

Sobald zur erweiterten Klasse ubergegangen wird, werden 
unabhangig vom Wissen des Bedienrechners nur noch Objekte 
10 der neuen Klasse erzeugt. 

Die neuen Klassen sind entweder erweiterte Klassen oder 
Klassen, die mit den bisherigen Klassen nichts zu tun ha- 
ben. 

15 

Das Datenbankprogramm 110 ist so ausgelegt, dafi nach einer 
Weiterentwicklung der gesamte Datenbestand zur Ursprungsklas- 
se in einen Datenbestand der erweiterten Klasse umgewandelt 
wird . 

20 

Das Erstellen der Tabelle T und das Umwandeln des Datenbe- 
standes in der Datenbank des Datenbankprogramms 110 werden 
durch Hilf sprogramme unterstiitzt. Diese Hilf sprogramme werten 
Beschreibungssprachen aus, mit deren Hilfe die Erweiterung 
25 von Klassen angegeben wird. 

Im folgenden werden Bedingungen angesprochen, die bei der Be- 
rucksichtigung von Allomorphie eingehalten werden mussen. 
Diese Bedingungen gelten auf der Ebene der Klassen, obwohl 
30 gemali Standard X.720 Allomorphie zunachst eine Eigenschaft 

eines Objekts ist, Im Standard X.720 sind folgende Bedingun- 
gen angesprochen: 



35 



Bedingungen fur die erweiterte Klasse in Abschnitt 
5.2.2.1, 
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Bedingungen fur sogenannte Programmpakete in den Ab- 
schnitten 5*2.2.1 und 5.2.2.2, 

Bedingungen fiir Kennzeichenwerte in den Abschnitten 
5 5.2.2.3 und 5.3.4.1, 

Bedingungen fur sogenannte Kennzeichengruppen in Ab- 
schnitt 5.2.2.4, 

10 - Bedingungen fiir Aktionen, Bestatigungen und Parameter in 
Abschnitt 5.2.2.54, 

Bedingungen fiir das Verhalten der Objekte in Abschnitt 
5.2.2.6, und 

15 

Bedingungen fur die Namensbindung in Abschnitt 5.3.4.1. 

Figur 5 zeigt in einem Teil a einen Ausschnitt aus einem so- 
genannten binaren Baum, der die Namensbindung von Objekten 

20 der Klasse A und A f festlegt. Namensbindung ist die fur das 
Festlegen eines eindeutigen Namens fur ein Objekt verwendete 
Zuordnung des Objektes zu einem sogenannten iibergeordneten 
Objekt. Gleiche Objektnamen fiir unterschiedliche Objekte kon- 
nen verwendet werden, wenn die Objekte jeweils zu einem ande- 

25 ren iibergeordneten Objekt gehoren. Aus dem Namen des uberge- 
ordneten Objekts und dem Namen der so untergeordneten Objekte 
entsteht dann ein im Steuerrechner 16 eindeutiger Name. Das 
ubergeordnete Objekt ist beim Erzeugen eines Objektes anzuge- 
ben. Das untergeordnete Objekt wird als im iibergeordneten Ob- 

30 jekt enthalten angesehen, englisch als "Containment" bezeich- 
net . 

Ein Objekt bl der Klasse B ist das ubergeordnete Objekt fiir 
die Objekte a2 und a3, die beide nach der Weiterentwicklung 
35 zur Klasse A 1 gehoren, jedoch unterschiedliche urspriingliche 
Klassen oC=A bzw. oC=A' haben. In der Tabelle T, die vom 
Schnittstellenprogramm 100 verwendet wird, sind die Namens- 
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bindungen vermerkt. Fur den im Teil A der Figur 5 gezeigten 
Ausschnitt des Namensbaumes ist in der Tabelle T vermerkt, 
dafi Objekte der Klasse B untergeordnete Objekte der ursprung- 
lichen Klasse A bzw. der Klasse A' enthalten. Bei jeder Wei- 
5 terentwicklung werden auch die Namensbindungen in der Tabelle 
T an den Namensbaum angepafit, der nach der Wei terentwicklung 
mafigeblich ist. 

Im Teil b der Figur 5 ist ein Zugriff auf Objekte beider 
10 Klassen A und A' dargestellt, nachdem auch der Bedienrechner 
24 beide Klassen A und A f kennt . Eine Wartungsnachricht WN3 
enthalt eine Filteranweisung Fl= ( (oC=A) ODER (oC=A f ) ) , in der 
festgelegt ist, dafi untergeordnete Objekte der Klasse A oder 
A T erfafit werden sollen. Das Klassenkennzeichen moC=B der 
15 Wartungsnachricht WN3 gibt an, dafi sich die Wartungsnachricht 
WN3 auf die Klasse B bezieht. Das Ob j ektkennzeichen moI=bl 
der Wartungsnachricht WN3 gibt an, dafi das Objekt bl bearbei- 
tet werden soil, d.h. das tibergeordnete Objekt ist. 

20 Beim Ausfilhren des Schnittstellenprogramms 100 in der Ver- 

mittlungsstelle 16 wird die Filteranweisung Fl unverandert an 
das Anwendungsprograirtm 102 gesendet. Das bedeutet insbeson- 
dere, dafi in der Filteranleitung Fl Operationen, die sich auf 
die ursprungliche Klasse A beziehen, nicht durch Operationen 

25 ersetzt werden, die sich auf die erweiterte Klasse A' bezie- 
hen. Diese Mafinahme gewahrleistet, dafi der Bedienrechner 24 
zwischen Objekten der ursprunglichen Klasse A und der ur- 
sprunglichen Klasse A f unterscheiden kann. 

30 Das Anwendungsprogramm 102 veranlafit, dafi mittels Datenbank- 
programm 110 aus dem Speicher 42 die Daten der Objekte a2 und 
a3 gelesen werden, die als ursprungliche Klasse die Klasse A 
bzw. A f haben. An das Schnittstellenprogramm 100 werden zwei 
nicht dargestellte Bestatigungsnachrichten BN3 und BN4 gesen- 

35 det. Im Schnittstellenprogramm 100 wird aus der Bestatigungs- 
nachricht BN3 eine neue Bestatigungsnachricht BN3 1 erzeugt, 
die das Klassenzeichen moC=A, das Objektkennzeichen moI=a2, 
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das Ursprungskennzeichen oC=A und das Hilf skennzeichen alio 
={} enthalt. Aus der Bestatigungsnachricht BN4 wird im 
Schnittstellenprogramm 100 eine Bestatigungsnachricht BN4 ' 
erzeugt, welche das Klassenkennzeichen moC=A' , das Objekt- 
5 kennzeichen 11101=33, das Ursprungskennzeichen oC-A' , und das 
Hilf skennzeichen allo={A} enthalt. 

Der CCITT-Standard X.734 "Information Technology - Open Sy- 
stems Interconnection - Systems Management: Event Report Ma- 

10 nagement Function" aus dem Jahre 1993 erlautert die Ereig- 

nissteuerung im Fuhrungsnetz 10, vgl . Figur 1. Es werden so- 
genannte Diskriminatoren verwendet, die Ereignisse innerhalb 
der Vermittlungsstelle 16 nur unter bestimmten Bedingungen an 
den Bedienrechner 24 weiterleiten . Nach der Weiterentwicklung 

15 der Klasse A zur Klasse A' geniigt es, die Diskriminatoren, 
welche die Klasse A betreffen, in Diskriminatoren umzuwan- 
deln, welche die Klasse A' betreffen. Werden nach der Weiter- 
entwicklung neue Diskriminatoren erzeugt, so wird die Klasse 
A durch die Klasse A' ersetzt, wenn die Klasse A als Auswahl- 

20 kriterium fur das Weiterleiten der Nachrichten angegeben ist. 
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Patentanspriiche 

1. Verfahren zum Betreiben eines Telekommunikationsnetzes 
(10, 12), 

bei dem ein Netzelement (16) an einem Netzknoten eines Tele- 
kommunikationsnetzes (12) von einem Steuerrechner (36) ge- 
steuert wird, 

im Steuerrechner (36) neben dem Betriebssystem mehrere Anwen- 
dungsprogramme (102, 104) gespeichert sind, bei deren Aus- 
fuhren Anwendungsobjekte (a2, a3) bearbeitet werden, 
die Anwendungsobjekte (a2, a3) je nach Zugehorigkeit zu einer 
Klasse (A, A 1 ) Daten mit einer vorgegebenen Datenstruktur so- 
wie vorzugsweise auch vorgegebene Verfahren zum Bearbeiten 
der Daten haben, 

zwischen einem Bedienrechner (24) und dem Steuerrechner (36) 
eine Verbindung aufgebaut wird, iiber die der Steuerrechner 
(36) mittels mindestens einer Wartungsnachricht (WN1 bis WN3) 
gewartet wird, 

die Wartungsnachricht (WN1 bis WN3) ein Klassenkennzeichen 
(moC) enthalt, das die Wartungsnachricht (WN1 bis WN3) einer 
Klasse (A, A f ) zuordnet, 

das Klassenkennzeichen (moC) der Wartungsnachricht (WN1 bis 
WN3) die im Bedienrechner bekannte Klasse (A) eines zu bear- 
beitenden Anwendungsob j ektes (a2, a3) angibt, 

beim Abarbeiten des Schnittstellenprogramms (100) anhand des 
Klassenkennzeichens (moC) ein Ersat zkennzeichen ermittelt 
wird, welches eine Ersatzklasse <A f ) angibt, der das zu bear- 
beitende Anwendungsob j ekt (a2, a3) im Netzelement (16) ange- 
hort, 

beim Abarbeiten des Schnittstellenprogramms (100) das Ersatz- 
kennzeichen (A ? ) in eine geanderte Wartungsnachricht (WNl f 
bis WN2 ? ) aufgenommen wird, 

und bei dem beim Bearbeiten der geanderten Wartungsnachricht 
(WNl f bis WN2 1 ) durch ein Anwendungsprogramm (102) das zu be- 
arbeitende Anwendungsob j ekt (a2, a3) als Ob j ekt der Ersatz- 
klasse (A ? ) bearbeitet wird. 
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2. Verfahren nach einem der vorhergehenden Anspriiche, da- 
durch gekennzeichnet , dafl beim Ermitteln des Ersatz- 
kennzeichens (A') eine im Speicher (122) des Steuerrechners 
(16) gespeicherte erste Tabelle (T) verwendet wird, in der 

5 dem Klassenkennzeichen (A) ein Ersatzkennzeichen (A 1 ) zuge- 
ordnet ist. 

3. Verfahren nach Anspruch 1 oder 2, dadurch gekenn- 
zeichnet, dafi das Anwendungsprogramm (102) nach dem Bear- 

10 beiten der geanderten Wartungsnachricht (WN1 ' ) eine Bestati- 
gungsnachricht (BN1) erzeugt, in der die beim Erzeugen des zu 
bearbeitenden Anwendungsobj ekts (a2, a3) angegebene Klasse 
(oC) als Klassenkennzeichen (moC) angegeben ist. 

15 4 . Verfahren nach Anspruch 3, dadurch gekennzeich- 
net, dafl beim Abarbeiten des Schnittstellenprogramms (100) 
aus der Bestatigungsnachricht (BN1) eine geanderte Bestati- 
gungsnachricht (BN1 ' ) erzeugt wird, die nur solche Daten ent- 
halt, die ein Anwendungsobj ekt (a2) der Klasse (A) hat, auf 

20 die sich die Bestatigungsnachricht (BN1) bezieht, 

und dafl die geanderte Bestatigungsnachricht (BN1 1 ) an den Be- 
dienrechner (24) gesendet wird. 

5. Verfahren nach Anspruch 3 oder 4, dadurch gekenn- 
25 zeichnet, dafi die beim Erzeugen des zu bearbeitenden An- 
wendungsobj ektes (a2, a3) angegebene Klasse (A, A') als Ur- 
sprungsklasse (oC) in den Daten das zu bearbeitenden Anwen- 
dungsobjekts {a2, a3) gespeichert ist, 

und daB beim Abarbeiten des Anwendungsprogramms (102) die Ur- 
30 sprungsklasse (oC) als Klassenkennzeichen (moC) verwendet 
wird. 

6. Verfahren nach einem der Anspriiche 3 bis 5, dadurch 
gekennzeichnet, dafl die Bestatigungsnachricht (BN1) 

35 ein Hilf skennzeichen (alio) enthalt, in welchem mindestens 
eine Klasse (A) bezeichnet ist, die im Bedienrechner (24) 
und/oder in mindestens einem anderen Bedienrechner als die 



GR 99 P 1391 

26 

Klasse (A) bekannt ist, zu der das zu bearbeitende Anwen- 
dungsobjekt (a2, a3) gehort, vorzugsweise zumindest die im 
Bedienrechner (24) bekannte Klasse (A) des zu bearbeitenden 
Anwendungsobjekts (a2, a3) . 

5 

• 7 . Verf ahren nach Anspruch 6, dadurch gekennzeich- 
net, dafi die Bestatigungsnachricht (BN1) neben dem Klassen- 
kennzeichen (moC) ein Ursprungskennzeichen (oC) enthalt, in 
welchem die Ursprungsklasse (A, A') angegeben ist. 

10 

8. Verf ahren nach Anspruch 6 oder 7, dadurch gekenn- 
zeichnet, daft mindestens eine im Bedienrechner (24) 
und/oder in mindestens einem anderen Bedienrechner fur das 
Anwendungsobjekt bekannte Klasse (A) als Allomorphklasse (al- 

15 lo) in den Daten des Anwendungsobjektes (a2, a3) gespeichert 
ist, 

und dafl beim Abarbeiten des Anwendungsprogramms (102) die Al- 
lomorphklasse (alio) als Hilf skennzeichen (alio) verwendet 
wird. 

20 

9. Verf ahren nach einem der Anspriiche 4 bis 8, dadurch 
gekennzeichnet , dafi die bzw. eine beim Abarbeiten des 
Schnittstellenprogramms (100) fur den Bedienrechner (24) er- 
zeugte Bestatigungsnachricht (BN1 1 ) das Hilf skennzeichen (al- 

25 lo) und/oder das Klassenkennzeichen (moC) und/oder das Ur- 
sprungskennzeichen (oC) enthalt, 

10. Verf ahren nach einem der vorhergehenden Anspriiche, da- 
durch gekennzeichnet, daft das Netzelement eine Ver- 

30 mittlungsstelle (16), ein Cross-Connector oder eine Konzen- 
tratoreinheit ist . 

11. Verf ahren nach einem der vorhergehenden Anspriiche, da- 
durch gekennzeichnet, dafl das Telekommunikationsnetz 

35 (12) ein Festnetz, ein Mobilf unknetz oder ein Netz mit einem 
Festnetzanteil und einem Mobilf unknetzanteil ist. 
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12. Verfahren nach einem der vorhergehenden Anspriiche/ da- 
durch gekennzeichnet , dafl das Schnittstellenprogramm 
(100) weitere Schnittstellenf unktionen zwischen dem Bedien- 
rechner (24) und den Anwendungsprogrammen (102, 104) aus- 

5 fiihrt, 

vorzugsweise eine Ereignissteuerung zum Festlegen der Bear- 
beitungsreihenf olge der Wartungsnachrichten (WN1 bis WN3) 
und/oder eine Anpassung der vom Bedienrechner (24) kommenden 
Nachrichten (WN1 bis WN3) an ein Protokoll zur Nachrichten- 
10 tibertragung innerhalb des Steuerrechners (16), 

und/oder eine Anpassung der von den Anwendungsprogrammen 
(102, 104) kommenden Bestatigungsnachrichten (BN1 , BN2) an 
ein vorgegebenes Protokoll zur Nachrichtenubertragung zwi- 
schen Bedienrechner (24) und Steuerrechner (16). 

15 

13. Verfahren nach einem der vorhergehenden Anspriiche, da- 
durch gekennzeichnet, dafi ein erstes Anwendungspro- 
gramm (102) zur Teilnehmerverwaltung, 

und/oder ein zweites Anwendungsprogramm zum Verwalten von 
2 0 Verbindungsleitungen zu anderen Vermittlungseinrichtungen, 

und/oder ein drittes Anwendungsprogramm zur Wartung der Ver- 
mittlungseinrichtungen, 

und/oder ein viertes Anwendungsprogramm (104) zur Verkehrs- 
messung der geschalteten Verbindungen (18) verwendet wird. 

25 

14 . Verfahren nach Anspruch 13, dadurch gekennzeich- 
net, dall die Anwendungsob j ekte (a2, a3) des ersten Anwen- 
dungsprogramms (102) fur jeweils einen Teilnehmer (Tln2, 
Tln3) die Teilnehmerdaten enthalten, vorzugsweise die Rufnum- 

30 mer und/oder die nutzbaren Telekommunikationsdienste . 

15. Verfahren nach einem der vorhergehenden Anspriiche, da- 
durch gekennzeichnet, dafi die Wartungsnachrichten 
(WN1 bis WN3) ein Namenskennzeichen (mol) fur den Namen des 

35 Anwendungsob jektes (a2, a3) enthalten, auf welches sich die 
Wartungsnachricht (WN1 bis WN3) bezieht. 
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16. Netzelement (16) zum Betreiben eines Telekommunikations- 
netzes (10, 12), d a d u r c h gekennzeichnet , dafl es ei- 
nen Speicher zum Speichern von Befehlen hat, bei deren Abar- 
beiten das Verfahren nach einem der vorhergehenden Anspriiche 

5 durchgeflihrt wird. 

17. Telekommunikationsnetz (10, 12), gekennzeichnet 
durch, ein Netzelement gemafi Anspruch 16. 
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Zusammenf assung 

Verfahren und Netzelement zum Betreiben eines Telekommunika- 
tionsnetzes 

Erlautert wird ein Verfahren zum Betreiben eines Telekommuni 
kationsnetzes . Ein Netzelement (16) an einem Netzknoten des 
Telekommunikationsnetzes wird von einem Steuerrechner (36) 
gesteuert, Der Steuerrechner (16) wird von einem Bedienrech- 
ner (24) aus gewartet . Beim Weiterentwickeln von Anwendungs- 
programmen (102, 104) wird Allomorphie beriicksichtigt , damit 
auch ein nicht weiterentwickelter Bedienrechner (24) den 
Steuerrechner (36) warten kann. Der Aufwand beim Berticksich- 
tigen von Allomorphie im Steuerrechner (36) ist klein, weil 
ein Schnittstellenprogramm (100) verwendet wird, in dem we- 
sentliche Bearbeitungsschritte fur alle Anwendungsprogramme 
(102,104) durchgefuhrt werden, die das Berucksichtigen von 
Allomorphie gewahrleisten . 
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(57) Abstract 



The invention relates to a method for 
operating a telecommunications network. A 
network element (16) situated on a node 
of the telecommunications network is con- 
trolled by a control computer (36). Said 
control computer (36) is controlled by an 
operator computer (24). Allomorphy is 
taken into consideration in the improve- 
ment of application programs (102. 104) so 
that even a non-improved operator com- 
puter (24) is able to control the control 
computer (36). Making allowance for al- 
lomorphy results in little additional com- 
plexity since an interface program (100) is 
provided for in which essential processing 
steps are executed for all application pro- 
grams (102, 104) and thus ensure that allo- 
morphy is taken into consideration. 
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Erlautert wird ein Verfahren zum 
Betreiben eines Telekommunikationsnetzes. 
Ein Netzelement (16) an einem Netzknoten 
des Telekommunikationsnetzes wind von 
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bau solcher offenen Systeme. Zum Ftthren des Tk-Netzes soil 
ein separates Ftihrungsnetz verwendet werden. Die Schnittstel- 
len zwischen Bedienrechner und Vermittlungseinrichtung sind 
in Protokollen Ql, Q2 und Q3 standardisiert . 

Die Anwendungsobjekte sind als Objekte einer objektorientier- 
ten Sprache definiert, z.B. in der Sprache C++ oder CHILL. 
Werden die Anwendungsprogramme weiterentwickelt, so muB ge- 
wahrleistet werden, daB das Ftihrungsnetz auch mit den neuen 



10 - Anwendungsprogrdfomen fehlerfrei arbeitet. Das bedeutet insbe- 

sondere, daB Anvfendungsobjekte, die vom Bedienrechner als zu 
einer urspriinglichen Klasse gehorend angesehen werden, nicht 
ohne weiteres .einer geanderten Ersatzklasse zugeordnet werden 
konnen . 

15 

Dieses Problem wird im CCITT-Standard X.720 (01/92) - "Infor- 
mation Technology - Open Systems Interconnection - Structure 
of Management Information: Management Information Model" - im 
Abschnitt 5*2.1 angesprochen. Im Abschnitt 5.2.3 des Stan- 

20 dards X.720 werden zwei Methoden zum Losen des Problems vor- 
gegeben. Bei der ersten Methode wird auf der Seite des Anwen- 
dungsprogramms eine Programmiertechnik verwendet, die Allo- 
morphie berticksichtigt . Allomorphie ist die Fahigkeit eines 
bestimmten Anwendungsobjektes der Ersatzklasse so geftihrt zu 

25 werden, als ware es ein Objekt der urspr ting lichen Klasse, 

wenn diese Fahigkeit durch MaBnahmen auf der Seite des Anwen- 
dungsprogramms entsteht. Die andere Methode besteht darin, 
daB auf der Seite des Bedienrechners MaBnahmen getroffen wer- 
den, welche auch bei einer Weiterentwicklung des Anwendungs- 

30 programms ein Zusammenarbeiten zwischen Bedienrechner und An- 
wendungsprogramm ermoglichen. 
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Es ist Aufgabe der Erfindung zum Betreiben eines Telekommuni- 
kationsnetzes ein einfaches Verfahren anzugeben, bei dem Al- 
lomorphie bertlcksichtigt wird. 
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Beschreibung 

Verfahren und Netzelement zum Betreiben eines Telekommunika- 
tionsnetzes 

Die Erfindung betrifft ein Verfahren zum Betreiben eines Te- 
lekommunikationsnetzes, kurz Tk-Netz, bei dem ein Netzelement 
an einem Netzknoten des Tk-Netzes von einem Steuerrechner ge- 
steuert'-wird. Das, Netzelement ist beispielsweise eine Ver- 
mittlungsstelle z|m Vermitteln von Verbindungen, ein soge- 
nannter Cross-Connector oder eine Konzentratoreinheit zum An- 
schluB mehrerer Teilnehmer an eine Verbindungsleitung. Im 
Steuerrechner slnd neben dem Betriebssystem zum Betreiben des 
Steuerrechners mehrere Anwendungsprogramme gespeichert, bei 
deren Ausfiihren Anwendungsobjekte bearbeitet werden. Zu den 
Anwendungsobjekten gehoren Daten mit einer vorgegebenen Da- 
tenstruktur sowie vorzugsweise auch vorgegebene Verfahren zinn 
Bearbeiten der Daten. Die Datenstruktur und die Verfahren 
sind abhangig von einer auch beim Erzeugen des jeweiligen An- 
wendungsobjektes anzugebenden Klasse. Zwischen einem Be- 
dienrechner und einem Steuerrechner wird eine Verbindung auf- 
gebaut, tiber die der Steuerrechner mittels Wartungsnach- 
richten gewartet wird. 

Derartige Verfahren werden zum FUhren des Tk-Netzes einge- 
setzt, wenn zum Beispiel als Netzelement eine neue Vermitt- 
lungseinrichtung in Betrieb genommen wird oder wenn spater 
Teilnehmerdaten in der Vermittlungseinrichtung geandert wer- 
den mtissen, wie es beim AnschluB neuer Teilnehmer oder beim 
Umzug eines bisherigen Teilnehmers der Fall ist. Leistungsf a- 
hige Verfahren zum Ftihren des Tk-Netzes entstehen, wenn soge- 
nannte offene Systeme verwendet werden, bei deren Programmie- 
rung weltweit geltende Standards beachtet werden. Beispiels- 
weise betreffen Standards der ISO (International Standardisa- 
tion Organization) und der ITU (International Telecommunica- 
tion Union) mit ihrem Organ ITU-T, friiher CCITT (Internatio- 
nal Telegraph and Telephone Consul tativ Committee) , den Auf- 
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Diese Aufgabe wird durch ein Verfahren mit den Merkmalen des 
Patentanspruchs 1 gelost. Weiterbildungen sind in den Unter- 
ansprtichen angegeben. 

5 Beim erfindungsgemaBen Verfabxen wird aus den Wartuhgsnach- 
richten beim Abarbeiten eines ftir mehrere Anwendungsprogramme 
genutzten Schnittstellenprogramms jeweils ein Klassenkennzei- 
chen ermittelt, in welchem die Klasse angegeben ist, auf die 
sich die Wartungsnachricht bezieht. Das Klassenkennzeichen in 

10 ,der Wartungsnachjicht gibt die im Bedienrechner bekannte 
Klasse eines zu fearbeitenden Anwendungsobjekt.es an. Durch 
die Weiterentwicklung kommt es vor, daB die im Bedienrechner 
bekannte Klasse von der tatsachlichen Klasse des Anwendungs- 
objekts abweicht. Beim Abarbeiten des Schnittstellenprogramms 

15 wird an Hand des Klassenkennzeichens ein Ersatzkennzeichen 
ermittelt, welches eine Ersatzklasse angibt, der das Anwen- 
dungsobjekt im Netzelement zugeordnet ist. Das Ersatzkennzei- 
chen wird in eine geanderte Wartungsnachricht aufgenommen. 
Beim Bearbeiten der geanderten Wartungsnachricht durch ein 

20 Anwendungsprogramm wird das Anwendungsobjekt dann als zur Er- 
satzklasse geherend bearbeitet. Dies ist mSglich, weil das 
Anwendungsobjekt allomorph zu der im Bedienrechner bekannten 
Klasse ist, die in der ungeanderten Wartungsnachricht vom Be- 
dienrechner ftir das Anwendungsobjekt vorausgesetzt worden 

25 ist. 

Das Schnittstellenprogramm ubemimmt zentral ftir mehrere An- 
wendungsprogramme die Zuordnung der Ersatzkennzeichen zu den 
Klassenkennzeichen. Beim erfindungsgemaBen Verfahren muB die- 
ser Schritt nicht in jedem Anwendungsprogramm sondern nur 
einmal im Schnittstellenprogramm programmiert werden. Bei 
mehreren hundert Anwendungsprogrammen je Steuerrechner ver- 
ringert sich dadurch der Programmier- , Wartungs- und Dokumen- 
tationsaufwand erheblich. Die Anwendungsprogamme werden von 
zusatzlichen Schritten freigehalten, die beim Berucksichtigen 
von Allomorphie notwendig sind, weil diese Schritte zentral 
im vorgelagerten Schnittstellenprogramm durchgefuhrt werden. 
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Ein Teil der zusatzlichen Schritte wird auch in nachgelager- 
ten Datenbanken durchgefiihrt, welche von den Anwendungspro- 
grammen genutzt werden. 

5 Das Ausftihren der Zuordnung von Ersatzkennzeichen und Hilfs- 
kennzeichen in einem zentralen Schnittstellenprpgramm ist 
moglich, weil Allomorphie beim erfindungsgemafien Verfahren 
auf Klassenebene definiert ist. Eine derartige Definition ist 
im Standard X.720 nicht erwSthnt aber dennoch standardgerecht . 

10 -Allomorphie auf Klassenebene bedeutet, daB alle Objekte der 
Ersatzklasse so Ijefuhrt werden konnen, als waren sie Objekte 
der urspriinglichen Klasse. Durch eine auf alle Objekte der 
Ersatzklasse bezogene Definition von Allomorphie entstehen 
dann keine Nachteile, wenn vorgegebene Programmierregeln be- 

15 achtet werden. Beispiele fiir solche Programmierregeln werden 
unten im Zusammenhang mit den Ausftihrungsbeispielen erlau- 
tert. 

Das erfindungsgemafie Verfahren erm6glicht es, die Vorgaben 
20 des Standards X.720 auf eine einfache Art und Weise einzuhal- 
ten. Die Anwendungsprogramme im Steuerrechner k5nnen mit ei- 
nem geringen Mehraufwand weiterentwickelt werden, wobei immer 
sichergestellt bleibt, daB auch bei unverandert gebliebenen 
Programmen im Bedienrechner keine Fehler beim Betreiben des 
25 Fiihrungsnetzes auftreten. 

In einer Weiterbildung wird im Schnittstellenprogramm eine 
Tabelle verwendet, mit der dem Klassenkennzeichen die Ersatz- 
kennzeichen zugeordnet werden. Die Tabelle ist im Speicher 

30 des Steuerrechners gespeichert. Ein Eintrag der Tabelle wird 
gelesen, indem eine dem Klassenkennzeichen zugeordnete Spei- 
cherzelle gelesen wird, die das zum Klassenkennzeichen geho- 
rende Ersatzkennzeichen enth&lt. Das Ermitteln des Ersatz- 
kennzeichens benotigt so nur einen einzigen Lesezugrif f auf 

35 den Speicher. Andern sich durch Weiterentwicklungen der An- 
wendungsprogramme die Ersatzkennzeichen, so miissen nur die 
Speicherinhalte neu programmiert werden. Das bedeutet, daB 
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der Inhalt der Tabelle leicht ausgetauscht Oder erweitert 
werden kann. 

Wird in einer anderen Weiterbildung durch das Anwendungspro- 
gramm nach dem Bearbeiten der geanderten Wartungsnachricht 
eine Bestatigungsnachricht erzeugt, in der die, beim Erzeugen 
des zu bearbeitenden Anwendungsobjektes angegebene Klasse als 
Klassenzeichen angegeben ist, so kann die Bestatigungsnach- 
richt vom Schnittstellenprogramm nachfolgend auf einfache Art 
weiter bearbeitdt werden. Beispielsweise kann beim Abarbeiten 
des Schnittstelfenprogramms an Hand des Klassenkennzeichens 
festgestellt werden, welche Daten aus der Bestatigungsnach- 
richt zu entfernen sind. Dazu wird die im Schnittstellenpro- 
gramm verwendete Tabelle so erweitert, da£ zu jedem Klassen- 
kennzeichen auch Eintragungen zu den erlaubten Daten gehdren. 
Das Schnittstellenprogramm erzeugt dann aus der Bestatigungs- 
nachricht eine neue Bestatigungsnachricht, die nur solche Da- 
ten eines Anwendungsobjekts der Klasse enthalt, auf, die sich 
die Bestatigungsnachricht bezieht. 

Die beim Erzeugen des zu bearbeitenden Anwendungsobjektes an- 
gegebene Klasse wird in einer Weiterbildung als Ursprungs- 
klasse in den Daten des zu bearbeitenden Anwendungsobjekts 
gespeichert. Beim Abarbeiten des Anwendungsprogramms wird die 
Ursprungsklasse dann als Klassenkennzeichen verwendet. Durch 
diese Vorgehensweise ist die Ursprungsklasse auf einfache Art 
und Weise verfiigbar. 

Enthalt die Bestatigungsnachricht in einer anderen Weiterbil- 
dung auch ein Hilfskennzeichen, in welchem mindestens eine 
Klasse bezeichnet ist, die im Bedienrechner und/oder in min- 
destens einem anderen Bedienrechner als die Klasse bekannt 
ist, zu der das zu bearbeitende Anwendungsobjekt gehort, so 
kann spater das Programm im Bedienrechner an Hand des Hilfs- 
kennzeichens ermitteln, wie die empfangene Bestatigungsnach- 
richt zu bearbeiten 1st. Dies ist insbesondere dann von Be- 
deutung, wenn die im Klassenkennzeichen der vom Bedienrechner 
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empfangenen Bestatigungsnachricht angegebene Klasse im Be- 
dienrechner noch nicht bekannt ist. Der Bedienrechner be- 
stimmt die Klasse, auf die sich die Bestatigungsnachricht be- 
zieht dann an Hand der im Hilfskennzeichen angegebenen Klasse 
bzw. Klassen. Das Hilfskennzeichen enthalt, mit anderen Wor- 
ten ausgedrtickt, die Klassen, zu denen das Anwendungsob j ekt 
allomorph ist. Enthalt die Bestatigungsnachricht neben dem 
Klassenkennzeichen auch ein Ursprungskennzeichen, in dem die 
Ur,sprungsklasse angegeben ist,. so lassen sich die Vorgaben 
des Protokolls ftij- den Nachrichtenaustausch im Steuerrechner 
und auch fur das irotokoll fur den Nachrichtenaustausch zwi- 
schen Bedienrechner und Steuerrechner erf alien. 

In einer anderen Weiterbildung wird mindestens eine im Be- 
dienrechner und/oder in mindestens einem anderen Bedienrech- 
ner fur das Anwendungsobjekt bekannte Klasse als Allomorph- 
klasse in den Daten des Anwendungsobjekts gespeichert. Beim 
Abarbeiten des Anwendungsprogramms wird dann die Allomorph- 
klasse als .Hilfskennzeichen verwendet. Durch diese MaBnahme 
entsteht eine ubersichtliche Datenstruktur, bei der die An- 
wendungsobjekte ihre Allomorphklassen selbst verwalten. Im 
Schnittstellenprogramm und im Anwendungsprogramm miissen keine 
zusatzlichen Mafinahmen hinsichtlich der Alloiaorphklasse ge- 
troffen werden. 

In einer anderen Weiterbildung ist das Schnittstellenprogramm 
auch fur andere Schnittstellenfunktionen zustandig. Bei- 
spielsweise ftir die Ereignissteuerung zum Festlegen der Bear- 
beitungsreihenfolge der Wartungsnachrichten oder ftir Proto- 
kollanpassungen dieser Nachrichten, englisch als "basic enco- 
ding" bezeichnet. Durch diese MaBnahme gibt es auf dem Steu- 
errechner nur ein einziges Schnittstellenprogramm, das ein- 
heitlich programmiert und gewartet wird. 



Im folgenden werden Ausfuhrungsbeispiele der Erfindung 
Hand der Zeichnungen erlautert. Darin zeigen: 



WO00/54520 PCT/EPOO/02070 



einen Teil eines Fiihrungsnetzes zum Fiihren eines 
Telekommuni kat ionsnet zes , 

die Weiterentwicklung einer ursprtinglichen Klasse A 
zu einer erweiterten Klasse A' , deren Objekte beim 
Betreiben des Fiihrungsnetzes wie Objekte der alten 
Klasse A gefiihrt werden konnen, 

das Bearbeiten von Nachrichten im Steuerrechner ei- 
ner Vejfmittlxingseinheit nach der Weiterentwicklung, 
wobei fin Objekt gefiihrt wird, das vor der Weiter- 
entwicklung erzeugt worden ist, 

das Bearbeiten von Nachrichten im Steuerrechner 
nach der Weiterentwicklung, wobei ein Objekt ge- 
fiihrt wird f das nach der Weiterentwicklung erzeugt 
worden ist, 

.die Namensbindung der Klassen A und A' sowie ein 
Zugriff auf Objekte der beiden Klassen mittels ei- 
ner Filterfunktion. 

Figur 1 zeigt einen Teil eines FUhrungsnetzes 10 zum Fiihren 
eines Telekommunikationsnetzes 12, kurz Tk-Netz 12 genannt. 

25 Das Tk-Netz 12 enthSlt eine Vielzahl von Vermittlungsstellen, 
von denen in Figur 1 die Vermittlungsstellen 14 und 16 darge- 
stellt sind. Zum Tk-Netz 12 gehfcren weiterhin Verbindungslei- 
tungen zwischen den Vermittlungsstellen, von denen in Figur 1 
eine Verbindungsleitung 18 zwischen der Vermittlungsstelle 14 

30 und der Vermittlungsstelle 16 dargestellt ist. Das Tk-Netz 12 
verbindet die Teilnehmer des Tk-Netzes 12, beispielsweise ei- 
nen an die Vermittlungsstelle 14 angeschlossenen Teilnehmer 
Tlnl und einen an die Vermittlungsstelle 16 angeschlossenen 
Teilnehmer Tln2. 

35 

Das Fiihrungsnetz *10 enthalt eigene Obertragungsstrecken 20 
und 22, die zu einem Bedienrechner 24 fiihren . Die Ubertra- 



Figur 1 



Figur 2 
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Figur t 3 



Figur 4 

15 



Figur 5 
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gungsstrecke 20 iibertragt Wartungsnachrichten vom Bedienrech- 
ner 24 zur Vermittlungsstelle 14 , um beispielsweise in der 
Vermittlungsstelle 14 Teilnehmerdaten des Teilnehmers Tlnl zu 
andern. Die Vermittlungsstelle 14 sendet ihrerseits Bestati- 
gungsnachrichten an den Bedienrechner 24, um die ordnungsge- 
mafle Bearbeitung der empfangenen Wartungsnachricht zu signa- 
lisieren. Die Obertragungsstrecke 22 dient zur bidirektiona- 
len Datenubertragung zwischen Bedienrechner 24 und Vermitt- 
lungsstelle 16. , . 

S 

Die Wartungsnachsichten werden in der Vermittlungss telle 14 
von einem Steuerrechner 34 und in der Vermittlungsstelle 16 
von einem Steuerrechner 36 bearbeitet. Die Datenstrukturen, 
auf die sich die Wartungsnachrichten beziehen, gehOren im Be- 
dienrechner 24 und in der Vermittlungsstelle 14 derselben 
Klasse A an. Die Vermittlungsstelle 16 enthalt dagegen Daten- 
strukturen einer Klasse A', die gegentiber der im Bedienrech- 
ner 24 vorausgesetzten Klasse A weiterentwickelt worden ist. 
Der fehlerfreie Betrieb des Fuhrungsnetzes 10 wird beztiglich 
der Vermittlungsstelle 16 dadurch gewahrleistet, daB beim 
Weiterentwickeln der Klasse A zur Klasse A' Allomorphie be- 
rticksichtigt worden ist. Was Allomorphie in diesem Zusammen- 
hang bedeutet, wird unten an Hand der Figur 2 erlautert. 

Beam in Figur 1 darges tell ten Ausfiihrungsbeispiel wird in der 
Vermittlungsstelle 14 die Klasse A verwendet, die beispiels- 
weise die Datenstruktur fur Teilnehmerdaten festlegt, z.B. 
die Rufnummer und die nutzbaren Dienste des Tk-Netzes 12. 
Teilnehmerdaten des Teilnehmers Tlnl sind in einem Objekt al 
gemaB der durch die Klasse A vorgegebenen Datenstruktur in 
einem Speicher 38 des Steuerrechners 34 gespeichert. Die 
Klasse A ist auch im Bedienrechner 24 bekannt, angedeutet 
durch den Buchstaben A in einem Speicher 40 des Bedienrech- 
ners 24. 

In der Vermittlungsstelle 16 wurde die Klasse A zur Klasse A' 
weiterentwickelt. Ein Objekt a2 enthalt beispielsweise die 
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Teilnehmerdaten des Teilnehmers Tln2. Das Objekt a2 wurde 
erstmalig im Speicher 42 gespeichert, bevor die Klasse A zur 
Klasse A 1 weiterentwickelt worden ist. Bei der Weiterent- 
wicklimg wurde das urspriingliche Objekt a2 aber umgewandelt, 
5 und zwar in ein erweitertes Objekt a2 der Klasse A', indem 
ein Datenfeld erganzt worden ist. Ein Objekt a3 im Speicher 
42 gehort zur Klasse A' und enthalt die Teilnehmerdaten eines 
Teilnehmers Tln3, dessen Anschlufi erst nach der Weiterent- 
wick^ung in der Vermittlungss telle 16 eingerichtet worden 

10 ... ist, Obwohl die|Programme im Bedienrechner 24 nur Objekte der 
Klasse A untersfiitzen, konnen die zur Klasse A 1 gehorenden 
Objekte a2 und a3 vom Bedienrechner 24 aus wie Objekte der 
Klasse A abgefragt, geandert oder neu eingerichtet werden. 
Die Erweiterungen der Klasse A 1 im Vergleich zur Klasse A 

15 kSnnen vom Bedienrechner 24 allerdings erst dann bearbeitet 
werden, wenn die Programme im Bedienrechner 24 zu einem spa- 
teren Zeitpunkt so geandert werden, dafi auch die Klasse A ? im 
Bedienrechner 24 bekannt ist. 

20 Figur 2 zeigt die Klassen A und A' sowie das urspriingliche 

Objekt a2 und das Objekt a3. An Hand der Figur 2 wird im fol- 
genden erlautert, was die Bezeichnung "allomorph zu w bedeu- 
tet. Die Klasse A f unterscheidet sich von der Klasse A nur 
durch ein zusatzliches Datenfeld 50. Die Datenstruktur der 

25 Klasse A wurde also urn das Datenfeld 50 erweitert, urn eine 
weitere Eigenschaft der Teilnehmer Tln2, Tln3 beim Betrieb 
der Vermittlungsstelle 16 berucksichtigen zu konnen, z.B. ob 
der Teilnehmer Tln2, Tln3 tiher einen Lichtwellenleiter oder 
iiber einen Kupferleiter an die Vermittlungsstelle 16 ange- 

30 schlossen ist. Die Klasse A' wird deshalb im folgenden auch 
als erweiterte Klasse A 1 bezeichnet. Ein Datenfeld 50 1 im Ob- 
jekt a3 enthalt als Datum einen Wert, der angibt, daB der 
Teilnehmer Tln3 mittels eines Lichtwellenleiters an die Ver- 
mittlungsstelle 16 angeschlossen ist. Das Objekt a3 wird all- 

35 gemein als erweitertes Objekt a3 bezeichnet. 



WO 00/54520 



Die Klasse, die beim E^zeugen eines;Objektes angegeben wird, 
wird als urspriingliche Klasse -dieses Objekts bezeichnet. Das 
Objekt a2 hatte als ursprtingliche Klasse die Klasse A, ange- 
deutet durch einen Pfeil 52. Das erweiterte Objekt a3 hat da- 
5 gegen. als ursprtingliche Klasse die erweiterte Klasse A\ an- 
gedeutet durch einen Pfeil 54-. 

Eine erste Moglichkeit zum Festlegen der Datenstruktur der 
Klasse A besteht darin,. die Klasse A 1 aus der Klasse A init- 
io, tels sogenannter jtfererbung zu erzeugen, die in objektorien- 
tierten Programmilsrsprachen definiert ist. Solche Program- 
miersprachen sind z.B. die Sprachen C++ und CHILL. Bei einer 
Vererbung wird durch den Programmierer angegeben, daB die er- 
weiterte Klasse A f . von der Klasse A samtliche Datenstrukturen 
15 und sogenannten Methoden zum Bearbeiten der Datenstrukturen 
tibernehmen soil. Weiterhin wird angegeben, daB die Klasse A f 
zusatzlich das Datenfeld 50 enthalt. Eine andere Moglichkeit 
zum Festlegen der Klasse A 1 besteht darin, diese Klasse neu 
zu definieren. In diesem Fall wird die Klasse A f so defi- 
20 niert, wie es bereits bei. der Klasse A der Fall war. Zusatz- 
lich wird jedoch noch das Datenfeld 50 definiert. Die Bezie- 
hung der tibereinstimmenden Teile der Klasse A. und der erwei- 
terten Klasse A 1 ist in Figur 2 mittels Strichlinien 56 dar- 
gestellt. 

25 

In einem gedachten Objekt a3* sind aus dem Objekt a3 alle Da- 
tenfelder und alle Methoden zum Bearbeiten der Datenfelder 
enthalten, die auch beim Einrichten des Teilnehmers Tln3 vor 
der Weiterentwicklung erzeugt worden waren, als es zwar die 

30 Klasse A, aber noch nicht die Klasse A 1 gab. Im Objekt a3* 
fehlt deshalb ein dem Datenfeld 50 bzw. 50' entsprechendes 
Datenfeld. Dieser Sachverhalt wird durch Strichlinien 58 ver- 
deutlicht. Das Objekt a3* ist eine Anschauungshilf e zum Ab- 
grenzen der Begriffe "kompatibel zu" und "allomorph zu". Ein 

35 Pfeil 60 verdeutlicht, daB das Objekt a3* kompatibel zur 

Klasse A ist, weil es genau die Datenstrukturen hat, die in 
der Klasse A vorgegeben sind. Das erweiterte Objekt a3 ist 
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dagegen allomorph zur Klasse A, vgl. Pfeil 62. Das Objekt a3 
hat die allomorphe Klasse A. 

Allomorphie ist die Fahigkeit der Objekte der Klasse A' so 
gefiihrt zu werden, als waren sie Objekte ihrer allomorphen 
Klasse A, wenn diese Fahigkeit durch MaBnahmen.^uf der Seite 
des Anwendungsprogramms entsteht. Bei einer stufenweisen Er- 
weiterung kann es mehr als eine allomorphe Klasse geben, z.B. 
die allomorphe Klasse der letzten Erweiterung und die allo- 
morphe klasse de^ vorletzten Erweiterung. 

Ein erweitertes Objekt hat nur dann eine allomorphe Klasse, 
wenn das erweiterte Objekt ohne die Erweiterungen zur allo- 
morphen Klasse kompatibel gemafi Standard X.720 Abschnitt 
5*2,2 ist. Insbesondere hat das erweiterte Objekt demnach al- 
le Attribute, Attributgruppen, FUhrungsfunktionen und Besta- 
tigungsverfahren, die auch in der allomorphen Klasse festge- 
legt sind. Durch das Beriicksichtigen der Allomorphie beim Er- 
weitern der Klasse A wird erreicht, daB das FUhrungsnetz 10 
auch nach der Erweiterung fehlerfrei arbeitet. 

Figur 3 zeigt das Bearbeiten von Nachrichten im Steuerrechner 
16 nach der Weiterentwicklung der Klasse A zur Klasse A 1 , wo- 
bei das Objekt a2 geftihrt wird, das vor der Weiterentwicklung 
als zur Klasse A gehorend angelegt worden ist. Beim Weiter- 
entwickeln der Klasse A zur Klasse A' wurde Allomorphie be- 
rticksichtigt, so daB Objekte der Klasse A 1 zur Klasse A allo- 
morph sind. Auflerdem wurden beim Weiterentwickeln alle Objek- 
te der Klasse A in Objekte der Klasse A 1 umgewandelt, indem 
Datenf elder und Methoden erganzt worden sind. 

Der Steuerrechner 16 enthalt ein Schnittstellenprogramm 100, 
das vom Bedienrechner 24 kommende Wartungsnachrichten, bei- 
spielsweise eine Wartungsnachricht WN1, bearbeitet und das 
Bestatigungsnachrichten, beispielsweise eine Bestatigungs- 
nachricht BN1 1 , an den Bedienrechner 24 sendet. Das Schnitt- 
stellenprogramm 100 ist die Schnittstelle zwischen dem Be- 
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dienr^chner 24 uiid mehreren Anwendimgsprogrammen im Steiier- 
rechner 16,, von denen in Figur 3 zwei Anwendungsprogramme 102 
und 104 gezeigt sind. Das Anwendungsprogramm 102 dient zum 
Verwalten der zu den an die Vermittlungsstelle 16 angeschlos- 
senen Teilnehmern Tln2, Tln3 gehSrenden Daten. Das Anwen^ 
dungsprogramm 104 wird zur Verkehrsmessung verwendet. 

Die vom Bedienrechner kommende Wartungsnachricht WN1 wird 
beim Abarbeiten. des Schnittstellenprogramms 100 an das Anwen- 
dungsprogramm 102jTals geanderte Wartungsnachricht WN1' wei- 
tergeleitet. FUr lias Anwendungsprogramm 104 bestimmte War- 
tungsnachrichten werdeh dagegen beim Abarbeiten des Schnitt- 
stellenprogramms 100 an das Anwendungsprogramm 104 weiterge- 
leitet, vgl. Pfeil 106. 

Nach dem Bearbeiten der Wartungsnachricht WN1 ' im Anwendungs- 
programm 102 erzeugt das Anwendungsprogramm 102 eine Bestati- 
gungsnachricht BN1 ftir die Schnittstelle 100. Hat das Anwen- 
dungsprogramm 104 eine Wartungsnachricht bearbeitet, so sen- 
det es ebenfalls eine Bestatigungsnachricht an das Schnitt- 
stellenprogramm 100, vgl. Pfeil 108. 

Beim Bearbeiten der Wartungsnachricht WN1 1 arbeitet das An- 
wendungsprogramm 102 mit einem ebenfalls im Steuerrechner 36 
vorhandenen Datenbankprogramm 110 zusammen, mit dem Teilneh- 
merdaten im Speicher 42 gespeichert, verandert, geloscht Oder 
gelesen werden. Das Anwendungsprogramm 102 sendet Anforderun- 
gen in Form von Nachrichten an das Datenkbankprogramm 110, 
beispielsweise die Nachricht Nl. Nach dem Ausftlhren der An- 
forderung in der Nachricht Nl sendet das Datenbankprogramm 
110 eine Ergebnisnachricht EN1 an das Anwendungsprogramm 102 
zurttck. Das Anwendungsprogramm 104 arbeitet mit einem eigenen 
Datenbankprogramm 112 zusammen, indem es Anf orderungen an das 
Datenbankprogramm 112 sendet, vgl. Pfeil 114, und indem es 
vom Datenbankprogramm 112 Ergebnisnachrichten empfangt und 
weiterbearbeitet, vgl. Pfeil 116. 
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Das Datenbankprogramm 110 benutzt ftir die Objekte der ur- 
sprunglichen Klasse A und die Objekte der weiterentwickelten 
Klasse A' dasselbe Zugrif fsverf ahren. Dies ist moglich, weil 
Kombinationsklassen verwendet werden, in denen die Daten- 
strukturen und Methoden der ursprtinglichen Klasse und der er- 
weiterten Klasse zusammengeftihrt sind. Eine Komfcinations- 
klasse KA ist die Kombination der Klasse A und der Klasse A f . 
Samtliche Objekte im Speicher 42, welche die allomorphe Klas- 
se A als ursprtingliche Klasse haben, werden mit der Weiter- 
entwicklung um d|e zusatzlichen Datenfelder der erweiterten 
Klasse A erweiteft. Die zus&tzlichen Datenfelder werden mit 
vorgegebenen Werten belegt. 

Die Wartungsnachricht WN1 enthalt ein Klassenkennzeichen moC, 
das die Klasse A als die Klasse angibt, auf welche sich die 
Wartungsnachricht WN1 bezieht- Ein Objektkennzeichen mol gibt 
das Objekt a2 an, auf das sich die Wartungsnachricht WN1 be- 
zieht. Die Wartungsnachricht WN1 wird vom Bedienrechner 24 
gesendet, um die Teilnehmerdaten des Teilnehmers Tln2 zu er- 
fahren. Im Bedienrechner 24 ist lediglich bekannt, daB diese 
Teilnehmerdaten in dem Objekt a2 enthalten sind, das im Steu- 
errechner 36 gespeichert ist. Die Wartungsnachricht WN1 ent- 
halt weitere nicht dargestellte Datenfelder. In einem dieser 
Datenfelder ist beispielsweise die auszuftihrende Leseoperati- 
on festgelegt. 

Beim Bearbeiten der Wartungsnachricht WN1 im Schnittstellen- 
programm 100 wird die im Klassenkennzeichen moC angegebene 
Klasse A ermittelt. An Hand der so ermittelten Klasse A wird 
beim Abarbeiten des Schnittstellenprogramms 100 mittels einer 
Tabelle T die Klasse A 1 als Ersatzklasse ermittelt und in das 
Klassenkennzeichen moC der Wartungsnachricht WN1 eingetragen. 
Die Tabelle T ist in einem Speicher 122 des Steuerrechners 36 
gespeichert. 

Die Wartungsnachricht WN1 1 betrifft mit dem Klassenkennzei- 
chen moC=A f die erweiterte Klasse A f . Der Wert des Objekt- 
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kennzeichens moI=a2 bleibt in der Wartungsnachricht WN1 1 un- 
yerandert. Ein Kennzeichen alio in der Wartungsnachricht WN1 1 
gibt alle Klassen an, die zur Klasse A* allomorph sind, d.h. 
im Ausfiihrungsbeispiel die Klasse A. Das Schnittstellenpro- 
5 gramm 100 entnimmt diese Klassen ebenfalls der Tabelle T. Die 
anderen Daten der Wartungsnachricht WN1 werden in die War- 
tungsnachricht WN1 1 tibernommen. Beim Erzeugen der zur War- 
tungsnachricht WN1 gehorenden Wartungsnachricht WN1 ' ftihrt 
das Schnittstellenprogramm 100- auch eine Protokollanpassung 
10 von einem Obertra&ungsprotokoll auf der Dbertragungsstrecke 
22 in ein Nachridhtenprotokoll durch, das innerhalb des Steu- 
errechners 36 verwendet wird. 

Die beim Bearbeiten der Wartungsnachricht WNl f durch das An- 
15 wendungsprogramm 102 erzeugte Nachricht Nl enth&lt einen Be- 
fehl Bl, der angibt, daB Daten gelesen werden sollen. Als Pa- 
rameter des Befehls Bl enthait die Nachricht Nl die Klasse 
A* , zu der die zu lesenden Daten gehoren, sowie das Objekt 
a2, dessen -Daten gelesen werden sollen. Das Anwendungspro- 
20 gramm 102 bearbeitet ausschliefilich Nachrichten, die sich auf 
Objekte der Klasse A' beziehen. Beztiglich der Klasse A sind 
im Anwendungsprogramm 102 keine weiteren MaBnahmen getroffen. 

Das Datenbankprogramm 110 greift beim Bearbeiten der Nach- 
25 richt Nl auf den Speicher 42 zu, urn die Daten des Teilnehmers 
Tln2 zu lesen, die im Objekt a2 gespeichert sind. Das Objekt 
a2 enth&lt auBerdem ein Ursprungskennzeichen oC, in dem die 
Klasse A angegeben ist, die beim Erzeugen des Objekts a2 an- 
gegeben worden ist. Das Datenbankprogramm 110 liest die mit 
30 dem Befehl Bl angeforderten Daten im Objekt a2 und tragt die- 
se Daten in die Ergebnisnachricht EN1 ein. In der Ergebnis- 
nachricht EN1 ist auBerdem mittels eines Antwortkennzeichens 
AB1 vermerkt, daB die Ergebnisnachricht EN1 das Ergebnis ent- 
halt, das beim Bearbeiten des Befehls Bl erzeugt worden ist. 
35 Weiterhin ist in der Ergebnisnachricht EN1 die Klasse A' als 
die Klasse angegeben, welche von der Ergebnisnachricht EN1 
betroffen ist. Das Ursprungskennzeichen oC=A wird ebenfalls 
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% vom Datenbankprogramm 110 in der Ergebnisnachricht EN1 an das 
Anwendungsprogramm 102 iibermittelt . 

Beim Abarbeiten des Anwendungsprogramms 102 wird vorausge- 
5 setzt, daB sich alle zu bearbeiteten Nachrichten auf die 

Klasse A' und nicht auf die Klasse A beziehen. ,purch das An- 
wendungsprogramm 102 wird der Wert des Ursprungskennzeichens 
oC=A als Wert des Klassenkennzeichens moC in der Bestati- 
gjangsnachricht BN1 tibernommen.* FUr diese Wertzuweisung ist es 

10 nicht erforderlich, daB das Anwendungsprogramm 102 Objekte 
der Klasse A bearbeiten kann. Auflerdem enthait die Bestati- 
gungsnachricht BN1 das Ursprungskennzeichen oC=A und die ab- 
gefragten Teilnehmerdaten des Teilnehmers Tln2. Das Schnitt- 
stellenprogramm 100 braucht sich aufgrund dieser Vorgehens- 

15 weise das Klassenkennzeichen der Wartungsnachricht WN1 nicht 
zu merken. 

Die Bestatigungsnachricht BN1 wird vom Schnittstellenprogramm 
100 bearbeitet und als Best&tigungsnachricht BN1 ' gemafl dem 

20 Obertragungsprotokoll auf der tJbertragungsstrecke 22 an den 
Bedienrechner 24 gesendet. An Hand der Tabelle T ermittelt 
das Schnittstellenprogramm 100, welche Datenfelder in der 
Nachricht BN1 nicht in Objekten der Klasse A enthalten sind. 
Diese Datenfelder werden nicht in die BestStigungsnachricht 

25 BN1 T iibernommen. 

Der Bedienrechner 24 empfangt die Bestatigungsnachricht BN1 1 
und kann sie wie eine Nachricht bearbeiten, die sich auf ein 
Objekt der Klasse A bezieht. Objekte der Klasse A f im Steuer- 
30 rechner 36 werden vom Bedienrechner 24 aus so geftihrt, als 
waren sie Objekte der Klasse A. Die Weiterentwicklung im 
Steuerrechner 36 schrankt die Betriebsmerkmale des Bedien- 
rechner s 24 somit nicht ein. 

35 Figur 4 zeigt das Bearbeiten von Nachrichten im Steuerrechner 
16 nach der Weiterentwicklung der Klasse A zur Klasse A 1 , wo- 
bei das Objekt a3 geftihrt wird, das erst nach der Weiterent- 
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wicklung erzeugt wird. Durch die Eingaben einer Bedienperson 
in den Bedienrechner 24 wird im Bedienrechner 24 eine War- 
tungsnachricht WN2 erzeugt, welche die Aufgabe hat, im Steu- 
errechner 16 das Objekt a3 fiir die Teilnehmerdaten des Teil- 
5 nehmers Tln3 zu erzeugen. Die Wartungsnachricht WN2 enthait 
deshalb in einem Befehlsfeld eine Codierung ftir^den Befehl 
"Erzeuge". Das Klassenkennzeichen moC in der Wartungsnach- 
richt WN2 kennzeichnet die Klasse A als die Klasse, auf die 
s±ch die Wartungsnachricht WN2.bezieht. Das Objektkennzeichen 
10 mol der Wartungsngchricht WN2 kennzeichnet das Objekt a3, das 
durch die Wartungsnachricht WN2 erzeugt werden soil. Die War- 
tungsnachricht WN2 enthait aufierdem noch weitere nicht darge- 
stellte Daten. 

15 Das Schnittstellenprogramm 100 bearbeitet die Wartungsnach- 
richt WN2 ebenso wie oben flir die Wartungsnachricht WN1 er- 
lautert. Beim Bearbeiten der Wartungsnachricht WN2 wird wie- 
derum die im Speicher 122 gespeicherte Tabelle T verwendet, 
urn fiir die im Klassenkennzeichen moC der Wartungsnachricht 

20 WN2 angegebene Klasse A die Ersatzklasse A* zu ermitteln und 
als Klassenkennzeichen moC der Wartungsnachricht WN2 f zu ver- 
wenden. Das Objektkennzeichen moI=a3 hat in der Wartungsnach- 
richt WN2 f den gleichen Wert, wie in der Wartungsnachricht 
WN2 . Auch die verbleibenden Daten werden aus der Wartungs- 

25 nachricht WN2 beim Ausftihren des Schnittstellenprogramms 100 
in die Wartungsnachricht WN2 1 ttbernommen. Zusatzlich wird im 
Kennzeichen alio der Wartungsnachricht WN2 1 vermerkt, daB die 
Klasse A die Klasse ist, zu der die Klasse A 1 allomorph ist. 
Die so erzeugte Wartungsnachricht WN2 f wird vom Schnittstel- 

30 lenprogramm 100 gemaB dem Protokoll im Steuerrechner 36 an 
das Anwendungsprogramm 102 gesendet. 

Das Anwendungsprogramm 102 sendet beim Bearbeiten der War- 
tungsnachricht WN2 f eine Nachricht N2 an das Datenbankpro- 
35 gramm 110, urn das Objekt a3 im Speicher 42 anlegen zu lassen. 
Die Nachricht N2 enthait verschliisselt den Befehl "Erzeuge", 
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die erweiterte Klasse A f sowie den Namen des anzulegenden Ob- 
jekts a3. 

Beim Bearbeiten der Nachricht N2 mittels des Datenbankpro- 
5 gramms 110 wird im Speicher 42 das Objekt a3 erzeugt, indem 
diesem Objekt bestimmte Speicherzellen zugewiej^en werden, die 
mit Anfangswerten belegt werden. Im Ursprungskennzeichen oC 
des Objekts a3 wird die Klasse A T vermerkt, weil diese Klasse 
beim £rzeugen des Objektes a3' angegeben wurde. Ein Kennzei- 
10 .chen alio im Obj|kt a3 weist auf die Klasse A hin, weil das 
Objekt a3 zu derf Klasse A allomorph ist. 

Das Datenbankprogramm 110 erzeugt eine Ergebnisnachricht EN2, 
urn das Erzeugen des Objekts a3 zu bestatigen. Die Ergebnis- 

15 nachricht EN2 enthalt ein Antwortkennzeichen AB2/ das angibt, 
daB die Ergebnisnachricht EN2 beim Bearbeiten -eines Befehls 
"Erzeuge" entstanden 1st. Weiterhin enthalt die Ergebnisnach- 
richt EN2 ein Kennzeichen, das auf die Klasse A 1 hinweist, 
das Ursprungskennzeichen oC=A f , das Kennzeichen allo=A sowie 

20 weitere nicht dargestellte Daten des Objekts a3. 

Die Ergebnisnachricht EN2 wird vom Anwendungsprogramm 102 be- 
arbeitet, wobei eine Bestatigungsnachricht BN2 erzeugt wird. 
In der Bestatigungsnachricht BN2 wird als Wert des Klassen- 
25 zeichens moC der Wert des Ursprungskennzeichens oC=A' verwen- 
det. Die anderen Daten der Ergebnisnachricht EN2 werden in 
die Bestatigungsnachricht BN2 tlbernommen. 

Beim Abarbeiten des Schnittstellenprogramms 100 wird nach dem 
30 Empfang der Bestatigungsnachricht BN2 eine Bestatigungsnach- 
richt BN2 ' gemaB dem auf der ttbertragungsstrecke 22 verwende- 
ten t)bertragungsprotokoll erzeugt. Die Bestatigungsnachricht 
BN2 1 enthalt alle Daten der Bestatigungsnachricht BN2, weil 
das Schnittstellenprogramm 100 an Hand der Tabelle T fest- 
35 stellt, daB keine Datenfelder entfernt werden mtissen, wenn 
die Bestatigungsnachricht BN2 als Klassenkennzeichen die 
Klasse A 1 hat. 
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Beim Bearbeiten der Bestatigungsnachricht BN2 ' im Bedienrech- 
ner 24 wird an Hand des Kennzeichens alio f estgestellt/ daB 
die Bestatigungsnachricht BN2 f Daten eines Objekts der Klasse 
5 A betrifft bzw. dafi die Bestatigungsnachricht BN2 1 so behan- 
delt werden kann, als wttrde sie Daten eines Objektes der 
Klasse A enthalten. Obwohl das Prqgramm im Bedienrechner 24 
nach der Weiterentwicklung im Steuerrechner 36 nicht veran- 
dert worden ist, konnen Objekte der Klasse A 1 im Steuerrech- 
10 ner 36 vom Steuerrechner 24 aus so gefiihrt werden , als waren 
sie Objekte der Klasse A. Solange im Bedienrechner A nur die 
Klasse A bekannt ist, werden in der Bestatigungsnachricht 
BN2 f auch nur die in Objekten der Klasse A enthaltenen Daten 
bearbeitet . 

15 

Aufgrund des an Hand der Figuren 3 und 4 eriauterten Verfah- 
rens ist es auch m6glich, Klassen zu untersttitzen, die zu 
mehreren Klassen allomorph sind. Wird z.B. die Klasse A* zu 
einer Klasse A" weiterentwickelt, so k5nnen Objekte zu den 

20 Klassen A* und A allomorph sein. Der Steuerrechner 36 kann 
dann von Bedienrechnern 24 ausgeftihrt werden, bei deren Pro- 
grammierung mindestens eine der Klassen A, A f oder A f ■ be- 
kannt war. Auf eine Unterstiitzung der Klasse A kann verzich- 
tet werden, sobald alle Bedienrechner zumindest die Klasse A' 

25 kennen. 

Das an Hand der Figuren 3 und 4 erl&uterte Verfahren wird bei 
Wartungsnachrichten zum Erzeugen und bei Wartungsnachrichten 
zum Lesen von Objekten angewendet. AuBerdem konnen mit diesem 
30 Verfahren Daten in Objekten verandert sowie Objekte geloscht 
werden. Damit diese Verfahren fehlerfrei arbeiten, muB der 
Bedienrechner 24 fahig sein: 

Die Best&tigungsnachrichten BN den zugehorigen Wartungs- 
35 nachrichten WN zuzuordnen, 
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das Kennzeichen alio in den Bestatigungsnachrichten BN zu 
lesen und auszuwerten, 

unbekannte Namensbindungen (vgl. Erlauterungen zu Fig, 5) 
5 zu iibergehen und unbekannte Kennzeichenwerte und Parame- 

ter zu iibergehen/ 

falls im Bedienrechner eine Datenbank vorhanden ist die 
« 'Ursprungsklasse eines Objekts zu speichern, 

unbekannte wahlfreie Werte zu iibergehen, und 

unbekannte Werte vom Datentyp "enumerated" zu iibergehen. 

15 Mit anderen Worten muB der Bedienrechner 24 so programmiert 
sein, daB von ihm aus Objekte in einen Steuerrechner mit gro- 
Berem Wissen gefiihrt werden konnen. 

Das Schnittstellenprogramm 100 hat folgende Merkmale: 

20 

Beim Erweitem einer Klasse ist es erforderlich, die er- 
weiterte Klasse in die Tabelle T aufzunehmen, das be- 
deutet, daB fiir jede erweiterte Klasse die Klassen ge- 
speichert werden miissen, zu denen die erweiterte Klasse 
25 allomorph ist. 

Die Namensbindungen, welche von der erweiterten Klasse 
betrof fen werden, miissen in der Tabelle T gespeichert 
werden . 

30 

Das Schnittstellenprogramm 100 soil aus den vom Anwen- 
dungsprogramm 102 kommenden Bestatigungsnachrichten BN 
die Daten entfernen, die nicht zur kompatiblen Klasse ge- 
horen, falls die an den Bedienrechner 24 gesendete Be- 
35 stStigungsnachricht BN die nicht erweiterte Klasse be- 

trifft. 
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- f Das Schnittstellenprogramm 100 muB Filterbef ehle bearbei- 
, ? ' ten konnen. Dies wird unten ,an Hand der Figur 5 noch ge- 
nauer erlautert. 

5 Das Anwendungsprogramm 102 erftillt die folgenden Anforderun- 
gen: 

Sobald zur erweiterten Klasse tibergegangen wird, werden 
/ linabhangig vom Wissen des Bedienrechners nur noch Objekte 
10" der neuen PgLasse erzeugt. 

Die neuen Klassen sind entweder erweiterte Klassen oder 
Klassen, die mit den bisherigen Klassen nichts zu tun ha- 
ben. 

15 

Das Datenbankprogramm 110 ist so ausgelegt, dafi nach einer 
Weiterentwicklung der gesamte Datenbestand zur Ursprungsklas- 
se in einen Datenbestand der erweiterten Klasse umgewandelt 
wird. 

20 

Das Erstellen der Tabelle T und das Umwandeln des Datenbe- 
standes in der Datenbank des Datenbankprogramms 110 werden 
durch Hilf sprogramme unterstiitzt . Diese Hilf sprogramme werten 
Beschreibungssprachen aus, mit deren Hilfe die Erweiterung 
25 von Klassen angegeben wird. 

Im folgenden werden Bedingungen angesprochen, die bei der Be- 
riicksichtigung von Allomorphie eingehalten werden miissen. 
Diese Bedingungen gelt en auf der Ebene der Klassen, obwohl 
30 gemaB Standard X.720 Allomorphie zunachst eine Eigenschaft 
eines Objekts ist. Im Standard X.720 sind folgende Bedingun- 
gen angesprochen: 



35 



Bedingungen far die erweiterte Klasse in Abschnitt 
5.2.2.1, 
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Bedingungen ftlr sogenannte Programmpakete in den Ab- 
schnitten 5.2.2.1 und 5.2.2.2, 

- . Bedingungen fiir Kennzeichenwerte in den Abschnitten 
5 5.2.2.3 und 5.3.4.1, 

Bedingungen fur sogenannte Kennzeichengruppen in Ab- 
schnitt 5.2.2.4, 

10 - Bedingungen iilr Aktionen, Bestatigungen und Parameter in 
Abschnitt 5.2.2.54, 

Bedingungen ftir das Verhalten der Objekte in Abschnitt 
5.2.2.6, und 

15 

Bedingungen ftir die Namensbindung in Abschnitt 5.3.4.1. 

Figur 5 zeigt in einem Teil a einen Ausschnitt aus einem so- 
genannten binaren Baum, der die Namensbindung von Objekten 

20 der Klasse A und A' festlegt. Namensbindung ist die fur das 
Festlegen eines eindeutigen Namens ftir ein Objekt verwendete 
Zuordnung des Objektes zu einem sogenannten iibergeordneten 
Objekt. Gleiche Objektnamen ftir unterschiedliche Objekte kon- 
nen verwendet werden, wenn die Objekte jeweils zu einem ande- 

25 ren iibergeordneten Objekt gehoren. Aus dem Namen des iiberge- 
ordneten Objekts und dem Namen der so untergeordneten Objekte 
entsteht dann ein im Steuerrechner 16 eindeutiger Name. Das 
iibergeordnete Objekt ist beim Erzeugen eines Objektes anzuge- 
ben. Das untergeordnete Objekt wird als im iibergeordneten Ob- 

30 jekt enthalten angesehen, englisch als "Containment" bezeich- 
net . 

Ein Objekt bl der Klasse B ist das iibergeordnete Objekt ftir 
die Objekte a2 und a3, die beide nach der Weiterentwicklung 
35 zur Klasse A 1 gehoren, jedoch unterschiedliche urspriingliche 
Klassen oC=A bzw. oC=A' haben. In der Tabelle T, die vom 
Schnittstellenprogramm 100 verwendet wird, sind die Namens- 
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bindungen vermerkt. Fiir den im Teil A der Figur 5 gezeigten 
Ausschnitt des Namensbaumes ist in der Tabelle T vermerkt > 
* daB Objekte der Klasse B untergeordnete Objekte der ursprting- 
lichen Klasse A bzw. der Klasse . A 1 enthalten. Bei jeder Wei- 
5 terentwicklung werden auch die Namensbindungen in der Tabelle 
T an den Namensbaum angepaBt, der nach der Weiterentwicklung 
maBgeblich ist. 

I^Teil .£> der Figur 5 ist ein Zugriff auf Objekte beider 
10 Klassen A und A f &argestellt, nachdem auch der Bedienrechner 
24 beide Klassen A und A 1 kennt. Eine Wartungsnachricht WN3 
enthalt eine Filteranweisung Fl=( (oOAJODEIKoC^ 1 ) ) , in der 
festgelegt ist, ,daB untergeordnete Objekte der Klasse A oder 
A f erfaBt werden sollen. Das Klassenkennzeichen moC=B der 
15 Wartungsnachricht WN3 gibt an, daB sich die Wartungsnachricht 
WN3 auf die Klasse B bezieht. Das Objektkennzeichen mol-bl 
der Wartungsnachricht WN3 gibt an, daB das Objekt bl bearbei- 
tet werden soli, d.h. das libergeordnete Objekt ist- - 

20 Beim Ausftihren des Schnittstellenprogramms 100 in der Ver- 

mittlungsstelle 16 wird die Filteranweisung Fl unverandert an 
das Anwendungsprogramm 102 gesendet. Das bedeutet insbeson- 
dere, daB in der Filteranleitung Fl Operationen, die sich auf 
die urspriingliche Klasse A beziehen, nicht durch Operationen 

25 ersetzt werden, die sich auf die erweiterte Klasse A 1 bezie- 
hen. Diese MaBnahme gewahrleistet, daB der Bedienrechner 24 
zwischen Objekten der ursprtlnglichen Klasse A und der ur- 
sprtinglichen Klasse A T unterscheiden kann. 

30 Das Anwendungsprogramm 102 veranlaBt, daB mittels Datenbank- 
programm 110 aus dem Speicher 42 die Daten der Objekte a2 und 
a3 gelesen werden, die als urspriingliche Klasse die Klasse A 
bzw. A' haben. An das Schnittstellenprogramm 100 werden zwei 
nicht dargestellte Bestatigungsnachrichten BN3 und BN4 gesen- 

35 det. Im Schnittstellenprogramm 100 wird aus der Bestatigungs- 
nachricht BN3 eine neue Bestatigungsnachricht BN3' erzeugt, 
die das Klassenzeichen moC=A, das Objektkennzeichen moI=a2, 
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das Ursprungskennzeichen oC=A und das Hilfskennzeichen alio 
= {} enthalt. Aus der Bestatigungsnachricht BN4 wird im 
Schnittstellenprogramm 100 eirie Bestatigungsnachricht BN4* 
erzeugt, welche das Klassenkennzeichen moC=A , / das Objekt- 
kennzeichen moI=a3, das Ursprungskennzeichen oC=A', und das 
Hilfskennzeichen allo={A} enthalt. 

Der CCITT-Standard X.734 "Information Technology - Open Sy- 
stems-Interconnection - Systems Management: Event Report Ma- 
nagement FunctioA" aus dent Jahre 1993 erlautert die Ereig- 
nissteuerung im ftthrungsnetz 10, vgl. Figur 1.. Es werden so- 
genannte Diskriminatoren verwendet, die Ereignisse innerhalb 
der Vermittlungsstelle 16 nur unter bestimmten Bedingungen an 
den Bedienrechner 24 weiterleiten. Nach der Weiterentwicklung 
der Klasse A zur Klasse A' gentigt es, die Diskriminatoren, 
welche die Klasse A betreffen, in Diskriminatoren umzuwan- 
deln, welche die Klasse A' betreffen. Werden nach der Weiter- 
entwicklung neue Diskriminatoren erzeugt, so wird die Klasse 
A durch die Klasse A' ersetzt, wenn die Klasse A als Auswahl- 
kriterium fur das Weiterleiten der Nachrichten angegeben ist. 
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Patentansprtlche 

1. Verfahren zum Betreiben eines Telekommunikationsnetzes 
(10, 12), 

5 bei dem ein Netzelement (16) an einem Netzknoten eines Tele- 
kommunikationsnetzes (12) von einem Steuerrechner (36) ge- 
steuert wird, 

im Steuerrechner (36) neben dem Betriebs system mehrere Anwen- 
djingsprqgramme (102, 104) gespeichert sind, bei deren Aus- 
10 ftihren Anwendung^pbjekte (a2, a3) bearbeitet werden, 

die Anwendungsob]ekte (a2, a3) je nach Zugehorigkeit zu einer 
Klasse {A, A f ) Daten mit einer vorgegebenen Datenstruktur so- 
wie vorzugsweise auch vorgegebene Verfahren zum Bearbeiten 
der Daten haben, 

15 zwischen einem Bedienrechner (24) und dem Steuerrechner (36) 
eine Verbindung aufgebaut wird, ilber die der Steuerrechner 
(36) mittels mindestens einer Wartungsnachricht (WN1 bis WN3) 
gewartet wird, 

die Wartungsnachricht (WN1 bis WN3) ein Klassenkennzeichen 
20 (moC) enthalt, das die Wartungsnachricht (WN1 bis WN3) einer 
Klasse (A, A 1 ) zuordnet, 

das Klassenkennzeichen (moC) der Wartungsnachricht (WN1 bis 
WN3) die im Bedienrechner bekarmte Klasse (A) eines zu bear- 
beitenden Anwendungsobjektes (a2, a3) angibt, 
25 beim Abarbeiten des Schnittstellenprogramms (100) anhand des 
Klassenkennzeichens (moC) ein Ersatzkennzeichen ermittelt 
wird, welches eine Ersatzklasse (A ? ) angibt, der das zu bear- 
beitende Anwendungsobjekt (a2, a3) im Netzelement (16) ange- 
hort, 

30 beim Abarbeiten des Schnittstellenprogramms (100) das Ersatz- 
kennzeichen (A f ) in eine ge&nderte Wartungsnachricht (WN1 1 
bis WN2 f ) aufgenommen wird, 

und bei dem beim Bearbeiten der geanderten Wartungsnachricht 
(WN1 ? bis WN2 1 ) durch ein Anwendungsprogramm (102) das zu be- 
35 arbeitende Anwendungsobjekt (a2, a3) als Objekt der Ersatz- 
klasse (A 1 ) bearbeitet wird. 
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2. Verfahren nach einem der vorhergehenden Ansprttche, da- 
durch gekennzeichnet, daB beim Ermitteln des Ersatz- 
kennzeichens (A') eine iia Speicher (122) des Steuerrechners 
(16) gespeicherte erste Tabelle (T) verwendet wird, in der 
dem Klassenkennzeichen (A) ein Ersatzkennzeichen (A f ) zuge- 
ordnet ist, 

3 . Verfahren nach Anspruch 1 oder 2 , dadurch g e k e n n - 
feicbnet, daB das Anwendungsprogramm (102) nach dem Bear- 
beiten der geancferten Wartungsnachricht (WNl f ) eine Bestati- 
gungsnachricht (BN1) erzeugt, in der die beim Erzeugen des zu 
bearbeitenden Anwendungsobjekts (a2, a3) angegebene Klasse 
(oC) als Klassenkennzeichen (moC) angegeben ist* 

4* Verfahren nach Anspruch 3, dadurch gekennzeich- 
net, daB beim Abarbeiten des Schnittstellenprogramms (100) 
aus der Bestatigungsnachricht (BN1) eine geanderte Bestati- 
gungsnachricht (BN1 f ) erzeugt wird, die nur solche Daten ent- 
hait, die ein Anwendungsobjekt (a2) der Klasse (A) hat, auf 
die sich die Bestatigungsnachricht (BN1) bezieht, 
und daB die geanderte Bestatigungsnachricht (BN1 ' ) an den Be- 
dienrechner (24) gesendet wird. 

5 • Verfahren nach Anspruch 3 oder 4 , dadurch gekenn- 
zeichnet, daB die beim Erzeugen des zu bearbeitenden An- 
wendungsobjekt es (a2, a3) angegebene Klasse (A, A 1 ) als Ur- 
sprungsklasse (oC) in den Daten das zu bearbeitenden Anwen- 
dungsobjekts (a2, a3) gespeichert ist, 

und daB beim Abarbeiten des Anwendungsprogramms (102) die Ur- 
sprungsklasse (oC) als Klassenkennzeichen (moC) verwendet 
wird. 

6. Verfahren nach einem der Ansprttche 3 bis 5, dadurch 
gekennzeichnet, daB die Bestatigungsnachricht (BN1 ) 
ein Hilfskennzeichen (alio) enthalt, in welchem mindestens 
eine Klasse (A) bezeichnet ist, die im Bedienrechner (24) 
und/oder in mindestens einem anderen Bedienrechner als die 
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Klasse (A) bekannt ist, zu der das zu bearbeitende Anwen- 
dungsobjekt (a2, a3) gehort, vorzugsweise zumindest die im 
Bedienrechner (24) bekannte Klasse (A) des zu bearbeitenden 
. Anwendungsobjekts (a2, a3) . 

5 

7. Verfahren nach Anspruch 6, dadurch gekennzeich- 

i net, dafl die Bestatigungsnachricht (BN1) neben dem Klassen- 

kennzeichen (moC) ein Ursprungskennzeichen (oC) enthalt, in 
welchem*die Urspr^ingsklasse (A, A 1 ) angegeben ist. 

io - I 

8. Verfahren nach Anspruch 6 oder 7, dadurch gekenn- 
zeichnet, daB mindestens eine im Bedienrechner (24) 
und/oder in mindestens einem anderen Bedienrechner flir das 
Anwendungsobjekt bekannte Klasse (A) als Allomorphklasse (al- 

15 lo) in den Daten des Anwendungsobjektes (a2, a3) gespeichert 
ist, 

und daB beim Abarbeiten des Anwendungsprogramms (102) die Al- 
lomorphklasse (alio) als Hilf skennzeichen (alio) verwendet 
wird. 

20 

9. Verfahren nach einem der Ansprtiche 4 bis 8, dadurch 
gekennzeichnet, daB die bzw. eine beim Abarbeiten des 
Schnittstellenprogramms (100) ftir den Bedienrechner (24) er- 
zeugte Bestatigungsnachricht (BN1 1 ) das Hilfskennzeichen (al- 

25 lo) und/oder das Klassenkennzeichen (moC) und/oder das Ur- 
sprungskennzeichen (oC) enthalt. 

10. Verfahren nach einem der vorhergehenden Ansprtiche, da- 
durch gekennzeichnet, daB das Netzelement eine Ver- 

30 mittlungsstelle (16), ein Cross-Connector oder eine Konzen- 
tratoreinheit ist. 

11. Verfahren nach einem der vorhergehenden Ansprtiche, da- 
durch gekennzeichnet, daB das Telekommunikationsnetz 

35 (12) ein Festnetz, ein Mobilfunknetz oder ein Netz mit einem 
Festnetzanteil und einem Mobilfunknetzanteil ist. 
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12. Verfahren nach einem der vorhergehenden Anspriiche, da- 
durch gekennzeichnet, daB das Schnittstellenprogramm 
(100) weitere Schnittstellenfunktionen zwischen dent Bedien- 
rechner (24) und den Anwendungsprogrammen (102, 104) aus- 
ftlhrt, 

vorzugsweise eine Ereignissteuerung zum Festle^en der Bear- 
beitungsreihenfolge der Wartungsnachrichten (WN1 bis WN3) 
und/oder eine Anpassung der vom Bedienrechner (24) kommenden 
Uachriehten (WNl^bis WN3) an ein Protokoll zur Nachrichten- 
iibertragung inne|halb des Steuerrechners (16), 
und/oder eine Anpassung der von den Anwendungsprogrammen 
(102, 104) kommenden Bestatigungsnachrichten (BN1, BN2) an 
ein vorgegebenes Protokoll zur Nachrichtentibertragung zwi- 
schen Bedienrechner (24) und Steuerrechner (16) . 

13. Verfahren nach einem der vorhergehenden Anspriiche, da- 
durch gekennzeichnet, daB ein erstes Anwendungspro- 
gramm (102) zur Teilnehmerverwaltung, 

und/oder ein zweites Anwendungsprogramm zum Verwalten von 
Verbindungsleitungen zu anderen Venaittlungseinrichtungen, 
und/oder ein drittes Anwendungsprogramm zur Wartung der Ver- 
mittlungseinrichtungen, 

und/oder ein viertes Anwendungsprogramm (104) zur Verkehrs- 
messung der geschalteten Verbindungen (18) verwendet wird. 

14. Verfahren nach Anspruch 13, dadurch gekennzeich- 
net, daB die Anwendungsobjekte (a2, a3) des ersten Anwen- 
dungsprogramms (102) ftir jeweils einen Teilnehmer (Tln2, 
Tln3) die Teilnehmerdaten enthalten, vorzugsweise die Rufnum- 
mer und/oder die nutzbaren Telekommunikationsdienste. 

15. Verfahren nach einem der vorhergehenden Anspriiche, da- 
durch gekennzeichnet, daB die Wartungsnachrichten 
(WN1 bis WN3) ein Namenskennzeichen (mol) ftir den Namen des 

Anwendungsob j ektes (a2, a3) enthalten, auf welches sich die 
Wartungsnachricht (WN1 bis WN3) bezieht. 
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16. Netzelement (16) zum Betreiben eines Telekommunikations- 
netzes (10, 12), dadurch gekennzeichnet, dafi es ei- 
nen Speicher zum Speichern von Befehlen hat, bei deren Abar- 
beiten das Verf ahren nach einem der vorhergehenden Ansprttche 
durchgeftthrt wird. 

17. Telekommunikationsnetz (10, 12), gekennzeichnet 
durch, ein Netzelement gemafi Anspruch 16. 
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PH AMOS - Philips Advanced 
Management and Operations 
t System - Functionality and 
architecture^ 

Andreas Hermann, Gerhard Hertlein, Joachim Lenzer, 
A ndreas Lingen, Walter Rothkegel, Norbert Sulzbacher 

The Philips Advanced Management and Operations System (PH 'AMOS) 
is the general management platform for telecommunications networks. 
PHAMOS is an open system which is based on international recommendations 
and industry standards. It supports the distributed management of 
network elements, equipment and services of heterogeneous networks 
and the distribution of management functions within a telecommunications 
management network (TMN). This article describes the functionality 
and architecture of PHAMOS. 
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Philips liMcaHiununicatintt^ ^cw 

works, microwave transmission, digital switching and 
data communications. 

PHAMOS provides the general functional and archi- 
tectural features tor a telecommunications manage- 
ment network (TMN) to support the management 
requirements of Network Operators and Service 
Suppliers such as: 

> provisioning 

> installation 

> maintenance 

> operation and 

> administration 

of telecommunications networks and services (3). 

PHAMOS provides management functions for tele- 
communications networks and services. In this context, 
a telecommunications network is assumed to consist 
of network equipment and the associated support 
equipment. A telecommunications service comprises 
a range of customised features. 

The basic concept behind PHAMOS is to provide a 
well-organised strategy for the interconnection of 
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various types of* Operations Systems (OS) and/or 
network equipments with the aim of exchanging 
management information and initiating respective 
measures using an agreed system architecture with 
standardised protocols and interfaces. 

The layered structure of PHAMOS consists of a large 
number of building blocks, implemented in C++, 
which can be reused for different applications. 

In defining the concept. Philips has taken into con- 
sideration that almost all network operators, private 
and public, already have an extensive infrastructure 
consisting of Operations Systems, networks and 
telecommunications equipment, which must be inte- 
grated into PHAMOS. In this context, it was also 
recognised that provision must be made for the access 
to the wide range of management information con- 
tained within the TMN and that this information must 
also be displayed and evaluated, it can be evaluated 
either by a human, an electronic device or a device 
of any other type such as alarm displays, alarm bells, 
video walls, post-processing systems, report genera- 
tors, expert systems etc. 
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2 The Telecommunications Management Network 

ATMN can vary in size from a very simple connec- 
tion between PHAMOS and a single telecommunica- 
tions unit to a very complex network interconnecting 
many different PHAMOS installations and tele- 
communications equipments. 

ATMN (Fig. 1) provides management functions and 
offers communication 

> between the PHAMOS installations (these can be 
NMSs of different kinds) and 

> to the telecommunications network as a whole or 
between parts of it. 

The telecommunications network consists of many 
types of network equipment, e. g.: 

> terminal multiplexers 

> add/drop multiplexers 

> local cross -connects 

> cross-connects and 

> special units related to the technology used, e.g. 
repeaters in SDH networks. 

.Associated equipment such as remote workstations 
and file servers is also supported. Each managed 
item of equipment is designated a Network Element 
(NE). 

Such a TMN (Fig. 1) is conceptually a separate net- 
work containing various PHAMOS installations 
which may be functionally different, it interfaces 
a telecommunications network at various points to 
exchange information with the network in order to 
control its operation. A TMN may use parts of the 
telecommunications network for communication pur- 
poses. In SDH the management information is ex- 
changed via the Qecc (Embedded Control Channel). 
Virtual X.25 connections of the telecommunications 
network are used in an X.25 net. 



2.1 liasic objectives of the TMN 

The principle of keeping the TMN logically distinct 
from the networks and services facilitates the distri- 
bution of the TNM functionality for centralised or 
decentralised PHAMOS implementations. This means 
that operators can perform the management of a wide 
range of geographically distributed equipment, net- 
works and services from any of several PHAMOS 
nodes. 

2.2 PHAMOS management functions 

The following five management functional areas 
of PHAMOS can be differentiated in accordance 
with [3]: 

> Fault management 

> Configuration management 

> Accounting management 

•> Performance management and 

> Security management. 

A sixth functional area is identified for PHAMOS 
itself, the System Management Application, i.e. the 
management of PHAMOS itself. 

These functional areas are supported by typical func- 
tions such as: 

-> Communication interfaces (X. Q) providing for the 
transmission of information betweenTMN elements 
(mainly by using OSI protocols) 

o data storage providing for the storage of information 
over a specific period using the persistent Manage- 
ment Information Base (MIB) 

o retrieval providing access to the MIB 

> security mechanisms which control the access to 
. information 

t> processing mechanisms for analysis and information 

manipulation, and 
t> user interfaces. 
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PHAMOS. as pan of a TMN. takes into account that 
telecommunications networks and sen-ices are a 
defined set of cooperating systems. 



2.3 The TMN functional architecture 

The TMN provides the means to transport and process 
information related to the management of telecommu- 
nications networks. The TMN functional architecture 
is based on functional blocks. The functional blocks 
provide the general TMN functions which enable 
a TMN to perform the TMN application functions. 
The TMN functional model [3| comprises functional 
blocks such as 

> PHAMOS Systems Function 

for the management of Network Element Functions 
(NEF): it processes information to support and/or 
control the realisation of various telecommunica- 
tion management functions. 

> Nenwrk Element Functions fNEF): 

the NEFis a functional block which communicates 
with the TMN for the purpose of monitoring and/or 
controlling the NE. This includes all telecommu- 
nications and support functions which are required 
for the management of the telecommunications 
network and telecommunications functions which 
are the subject of management. 

> Workstation Functions (WSF) 

which allow the management information user 
to interact remotely with PHAMOS. They pro- 
vide the means to interpret TMN information. 
They also include a man-machine-interface 
using the graphical user interface (GUI) of 
PHAMOS. 

> Data Communication Functions ( DCF); 

these are used for the transfer of information be- 
tween functional blocks. Their primary role is to 
provide information transport mechanisms in- 
cluding routing and relaying functions. The standard 
transport media is a LAN conforming to IEEE 
802.3 or CCITTX.25. 

■> Mediation Functions (MF); 

mediation functions process information from 
NEFs and in some cases from QAFs (see below), 
i.e. they adapt, filter and condense data as required 
by the PHAMOS installations. The mediation func- 
tions can be divided into the following functional 
components: 

- Information Conversion Function for the con- 
version of messages. This function characterises 
systems which have a mediation function and 
must always be available. 

- Management Application Function which need 
not necessarily be available. Examples of such 
functions are temporary storage, filtering, thresh- 
olding, data concentration, security, testing, 
etc. 

-> Q Adapter Function iQAF): 

QAFs are used to connect to the TMS those NEFs 
which do not support standard TMN interfaces. 
tv,.., nvi ,sf -* OAF k (o Translate between 



3 The PHAMOS architecture 
3.1 Features 

PHAMOS - the Philips Advanced Management 
and Operations System 

> provides mechanisms for customers, value-added 
service providers and other adm in istrat ions to access 
management functions via remotely accessible 
interfaces of the PHAMOS SW-components: 

> minimises the management reaction time to network 
events by means of a scalable architecture (Fig. 3^ 
which allows for the distribution of PHAMOS 
SW-components to multiple servers. The smallest 
possible configuration is a single workstation 
whereas the high end configuration consists or 
multiple servers with various works rations/^- ter- 
minals and optional mirrored disks, a "hot-stand- by- 
server and communication servers: 

> supports the management of any number of network 
elements, ranging" from small configurations to 
nationwide networks, by the same means as de- 
scribed above; 

> offers mechanisms for distributing management 
functions within a TMN. e.g. to provide different 
or identical PHAMOS application services at 
different locations (PHAMOS installations); 

.> supports the management of heterogeous networks, 
equipment and services within the telecommuni- 
cations environment; 

■> provides mechanisms for the interworking between 
separately managed networks: 

o provides mechanisms for technological and func- 
tional advances including migration capabilities 
to enhance early implementations and allow future 
refinements and extensions. 



3.2 Overview of the PHAMOS architecture 

3.2,1 The hardware platform 

PHAMOS operates on a wide range of hardware 
configurations ranging from a stand-alone system 
to control a limited number of network elements to 
a high availability system including a variable number 
of servers, workstations, mirrored disks and "hot- 
standby" servers which are capable of controlling a 
nationwide network. 

The hardware servers, HP 9000 Series 8 x ? computer 
systems, used in the current versions of PHAMOS. 
are based on HP's Precision Architecture RISC 
(PA- RISC) technology. 

I/O slots are available for 

> parallel and serial ports 

> IEEE 802.3 LAN controllers 

> X.25 boards, and 

> hard disk controllers. 

HP Series 700 workstations (colour or monochrome) 



Workstations * X- Terminals 
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Fig. 3 : PHAMOS hardware architecture 



functional units of the PHAMOS architecture can 
therefore be easily distributed. 

HP 700/RX X terminals provide a cost-effective 
solution for the PHAMOS graphical user interface. 



3.2.2 The operating system 

The UNIX operating system runs on the hardware 
platform. It complies with AT&T System V.3. the 
Svstem V-Interface Definition (SVID 2), the X/Open 
Portability Guide Issue 3 (XPG3). IEEEPOSIX 1003. 1 
andFlPS 151- U Apart from UNIX, international stan- 
dards and industry standards such as CCITT Re- 
commendations of the X.200. X.400. X.500, X.600, 
X.700 [5] series. RAM, NFS and LU 6.2 are 
supported. 



3.2.3 The network management server OpenView 

The generic network management server OpenView 
is used above the operating system layer. The basic 
functions of OpenView include: 

> Map Handling 
providing mechanisms for editing network topolo- 
gies (maps), for customising the views of maps, 
submaps (which can be refined recursively) and 
network nodes and for connecting applications 
to map entities. PHAMOS utilises these basic 
mechanisms proerammatically. i.e. the system 
provides default map configurations (depending 



on the functionality of the network elements). 
These default configurations can be modified 
by a super-user using the standard editing func- 
tions. 

> Communication Infrastructure and Object 
Registration Services 

providing basic mechanisms for the communication 
between managers and agents. These can be located 
inside PHAMOS or externally in the telecommu- 
nications network or in other PHAMOS installations. 
Due to the location transparency feature of Open- 
View the PHAMOS managers and agents need not 
know the physical location of their communication 
partners. 

> Event Sieving ; 

event sieves are mechanisms by which managers 
can request the Communication Infrastructure to be 
notified of certain events only. These events can be 
generated by Object Managers (OM) with agent 
functions within PHAMOS (see Section 3.3) - and 
more relevant - by agents located in the network 
elements. 



3.2.4 OSF/Motif and X- Windows 

The following components conforming to industry 
standards are" used for ;he PHAMOS man-machine 
interface: 

> XI I Release 4. and 
■> OSF/Motif Release LI. 
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Tlie PH AMOS graphical user interface was developed 
in accordance with the OSF/Motif Style Guide [61 
thus facilitating easy introduction to the system. 



3.2.5 The data storage system 

In the area of management systems the repository of 
information to be used in management applications is 
called a Management Information Base (MIB). The 
MIB of PH AMOS is directly related to the information 
Model (IM) of PHAMOS. An IM consists of managed 
object (MO) class definitions which are described 
in accordance with the GDMO (Guidelines for the 
Definition of Managed Objects [l] andASN.l (Ab- 
stract Syntax Notation 1 [2]). As the MIB is only a 
conceptual model of all knowledge available in an 
OS. it is necessary to map it to concrete storage 
structures either as persistent information in a file 
or database system or as volatile data within a 
PHAMOS process. Persistent storage of data in an 
OS is necessary for the following reasons : 

> The current status and configuration of NEs must 
be kept to allow for recovery procedures in case of 
NE failure or outage. 

> Read requests for MOs which are contained in an 
NE can be cached and therefore more efficiently 
served. For this purpose, only a database query 
is required and the need for the resource-con- 
suming communication via CMIS is reduced to a 
minimum. 

> The information about MOs and services not con- 
tained in an NE (OS objects) must be administered 
in a central repository. 

> An efficient way to address MOs, attributes etc. 
in the internal communication between PHAMOS 
components is the mapping of complex identifiers 
used in CM3P to simple C++ data structures via 
database query. 

For the storage of most of the persistent data a rela- 
tional database management system (RDBMS) has 
been chosen, because 

> well-defined methods concerning data modelling 
have been established (e.g. entity-relationship 
modelling (ERM)) which can easily be transformed 
into relational storage structures; 

> the semantics and the theory of RDBMS are well 
defined in the relational calculus: 

> there is a standardised language to access and query 
a database (Standard Query Language - SQL) 
which can be easily embedded into normal pro- 
gramming languages like C and C++\ 

■> it is possible to exchange one RDBMS for another 
without major effort and to communicate between 
RDBMSs via gateways: 

> they are commercially available and stable and 
expertise with respect to RDBMS (e.g. tuning) 
is widelv available, and 

> it is possible (0 establish distributed databases 
which arc transparent to the end user. 
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not easy to map an object-oriented view, provided 
by the IM. to a relational database scheme. 

For this purpose, a set of rules were defined to trans- 
form an IM to the first iteration of a data model, more 
precisely an ERM. This ERM has to be fine tuned 
by removing redundant information from the IM. 
taking into account the frequency and the type of 
access to the data, the performance requirements 
and other conditions. 

In addition, special tables have been defined to allow 
for the efficient storage of MO identifiers and the 
very important containment relationship between 
MOs. 



3.2.6 The system management application 

Due 10 its complexity, a PHAMOS system requires a 
special management application for the management 
of all components of a PHAMOS installation. This 
application is called the System Management Applica- 
tion (SMA) which conforms to the general PHAMOS 
architecture (see Section 3.3) and applies to all 
management components of PHAMOS. The SMA 
includes applications with an OSF/Motif user inter- 
face for SMA functions and Object Managers with 
SMA management functionality. The INGRES data- 
base is used for persistent data storage. 

All entities to be managed are modelled as Managed 
Objects (MO). Examples of SMA managed objects 
are: 

> Elements of PHAMOS and the UNIX operating 
system: files, disks, printers, backup tapes etc.. 

> PHAMOS processes. 

> hardware components, e.g. physical disks, network 
interfaces, workstations. 

Since PHAMOS is decentrally structured, it must be 
possible to distribute SMA also. This requirement is 
fulfilled by partitioning the SMA functionality into 
three layers : 

> User Interface Layer 

The user interface layer contains the SMA appli- 
cations which directly interface to the user. These 
applications are uniformly integrated into the 
overall PHAMOS user interface. 

o Functional Layer 
The functional layer contains the implementations 
of the SMA management strategies. Example: The 
functional layer of the SMA security administration 
component contains the code necessary to define 
a new PHAMOS user. However, it does not modify 
UNIX files when making the user known to the 
operating system. 

> Information Access Layer 

The object managers of the information access 
layer contain the proxy objects for system entities 
such as UNIX files, directory trees, disks etc. 
When u new network operator is defined, the SMA 
functional layer accesses the proxy objects lor 
"/etc/passwd". "/etc/ypaliases" etc. 

The communication between the SMA components 
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i ri(V:iscruc f .urc is current ly based on CMOT and 
RCP and -a : 1 1 migrate to OSF/DCE :n the future. 
An important aspect of the communications infra- 
structure :s the secure authentication of the com- 
munication partners. At the moment, a simple DES 
algorithm is used to check the credentials supplied 
by" a service requestor. Later PHAMOS releases 
will employ the RSA algorithm for secure authen- 
tication. 

The PHAMOS system management application 
as currently implemented covers the following as- 
pects: 

> Installation and configuration of the platform for 
the PHAMOS software 

The platform includes all hardware components 
and the system software. The SMA supports the 
initial installation, the upgrades and extensions 
of the platform and the administration of all relevant 
configuration parameters. 

> Installation, configuration and administration oj 
the PHAMOS application software 

The SMA provides user- friendly installation 
and configuration utilities to manage PHAMOS 
software releases. This category includes database 
management facilities to convert the database 
contents, if the database model changes with a 
new PHAiMOS software release. 

> Configuration of ' hotiskeeping operations 

The SMA provides facilities for automatic back- 
up, log and trace file management. Housekeep- 
ing includes mechanisms for the orderly (re-) 
start and shutdown of workstations and PHAMOS 
servers. 

> Diagnostic and performance analysis tools 
These tools are provided by the SMA to assess the 
current state of the hardware and software com- 
ponents and to predict future shortfalls in per- 
formance. 

> Security administration 

The SMA provides the complete security frame- 
work for PHAMOS. All information relevant to 
security is kept in a separate security database. 
The SMA provides a set of convenience objects for 
accessing data in this database. The PHAMOS 
security model is based on "access profiles'*. An 
access profile defines a set of operations and a set 
of managed objects on which these operations may 
be executed. 

The management authentication of a PHAMOS 
user is determined by the set of. access profiles 
which has been assigned to him/her by a security 
administrator. The security administration contains 
all the facilities and applications necessary to 
create, modify and delete PHAMOS users and 
access profiles and to supervise the state of the 
security database. 

> User authentication 

The current PHAMOS version employs a user ID/ 
password scheme to authenticate a PHAMOS user. 
In the next PHAMOS release even tighter security 
mechanisms will be introduced. The user authen- 
tication will i hen be executed using Smart Cards 
performing an RSA algorithm. 



3.2.7 Cuinmuiiiauiun Interfaces 

Several classes of interfaces have been defined by 
international standards bodies iCGTT. ISO. ETSI 
etc.) to provide for communication between equip- 
ment from different suppliers. These interfaces 
inciude: 

> Q-interface for the communication between Op- 
erations Systems \OS) and Network Elements 
iNE). 

> Qecc- interface (embedded control channel) using 
DCCm and DCCr channels for the communication 
between Network Elements. 

> F- interface for the remote connection of work- 
stations to an OS. 

> X-interface for the interconnection of management 
systems or Telecommunications Management Net- 
works. 

Fii>. 4 shows the implementation of the OSI protocol 
stack in PHAMOS in accordance with CCITT 
Recommendations G.773. Q.Sll andQ.8l2.The inter- 
faces are accessible by applications via an Application 
Program Interface ( APH. At the application layer, two 
types of protocol profiles are supported: 

> -he Common Management Information Service 
Element (CMISE^ which provides transaction type 
services and 

> the File Transfer and Access Management (FTAM) 
which provides file transfer type services. 

The lower layers support three profiles which are 
briefly described as follows: 

> A connectionless mode interface using ISO8802-2 
tvpe LANs and SCMA/CD (Ethernet) referred 
to as QB3 in G.773 or as CLNS I in Q.SIL 

> an interface using the ISO Internet Protocol over 
the X.25 protocol (QB2, CLNS2). and 

> a packet interface using X.25 (QBKCONS1). 

PHAMOS can also communicate over other networks, 
e.g. ISDN, leased lines, SDH payload etc. This is 
achieved by front ends operating as communication 
servers. 



3.3 The Object Oriented Approach 

Fig. 5 illustrates the general PHAMOS software 
architecture. PHAMOS is based on an object-oriented, 
hierarchical architecture consisting of two abstract 
entities: applications (Fig. 6) and object managers 
(Fig. 7). These abstract entities consist of the layers 
described as follows. 



3.3.1 Presentation Layer 

The presentation la>er exists in applications only. It 
is used for the visual representation of the entities ;o 
be managed and for their manipulation. PHAMOS 
uses t wo types of i;>er inter f ac e : 

> graphic-basal representation via maps and 

> text-based representation via dialogue boxes 
iFi«.S). 
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Fig. 9: PHAfrlOS platform approach 



accordance with the generic PHAMOS architec- 
ture. The database design, the design of the net- 
work topology and the composition of the dialogue 
boxes are executed in this phase. A prototype is 
generated using the OSF/Motif User Interface 
Generator. 

> Low Level Design Specification 
This specification defines the interfaces of the 
different PHAMOS building blocks, the message 
flow between them and the computational structure 
of their methods and functions. The interfaces 
of most components are closely related to the 
information model and are automatically generated 
by a GDMO tool package. 

•> Coding and unit test 
PHAMOS is wntten in C++. The module test is 
suported by a C-h- softbench. 



■> integration rest 

A central repository supported by a .software 
management and version control tool from Aide de 
Camp is used for the system integration. The com- 
pilation is controlled by GNU make. The system is 
integrated incrementally in accordance with the 
static and dynamic dependencies of the diverse 
PHAMOS building blocks which are automatically 
evaluated by analysing the C++ source. 

> System test 

The system test starts when a PHAMOS system is 
completely integrated. The system test is performed 
in the development laboratory following a system 
test plan. In contrast to the integration test this is a 
black box test. i.e. the tests are run at the external 
interfaces of the PHAMOS application. 



5 Summary 

PHAMOS - the Philips Advanced Management and 
Operations System - is a universal management sys- 
tem platform based on international standards and 
industry standards. It provides numerous services 
for the central or decentral control of the config- 
uration, operation, management and maintenance 
of large, possibly heterogeneous telecommunications 
networks. PHAMOS uses parts of the network for its 
own internal communication with its components. 
In all other aspects, however. PHAMOS is independent 
of the network. 
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Competition and the fast pace of technological evolution in today's global 
telecommunications industry are placing unique demands on the flexibili- 
ty of operations support software systems. The industry must be capable 
of rapidly introducing new services, technologies, and organizational 
structures. Networks must be capable of being partitioned for various 
applications and administered based on complex ownership relationships 
among the various network components. User permissions must be 
readily adaptable to reflect various combinations of services, network par- 
titions, and work functions. To meet the time constraints of the market, 
telecommunications providers require the ability to configure systems to 
meet their needs without relying on traditional software development 
intervals and external software development resources. Traditional 
software development methodologies generally do not provide the timeli- 
ness and flexibility required. The Service Design and Inventory (SDI) sys- 
tem—also known as the Attribute Design Database System (ADDS)— has 
achieved a high degree of reusability and customer-configurable adaptabil- 
ity through a unique application of object-oriented technology. 



Introduction 

The Service Design and Inventory 
(SDI) system is an exceptionally adaptable 
object-oriented software asset that has 
achieved the integration of a wide range of 
functionality and a high degree of software 
reuse across diverse customer applications. 
SDI supports several application functions 
within the network management layer of the 
telecommunications management network 
(TMN) architecture (see Figure 1). Within 
the network management layer, SDI acts as 
the database of record for all network-related 
information, including the following: 
- Network locational information, including 
geographic coordinates of structures con- 
taining network equipment (customer 
offices, access serving offices, central 
offices, and outside plant locations), as well 
as physical locations of equipment within 
an office; 



- Physical network components, including 
equipment and transmission media (for 
example, fiber, coaxial radio, and 
microwave), equipment port terminations, 
and cabling connections within and 
between equipment; and 

- Network path connections, including high- 
line and lower levels of transport facilities 
and service-providing circuits. 

Much of the application functionality 
within the network design and network 
inventory management modules of SDI 
revolves around the management of this 
highly interrelated network information, 
including tools supporting network office and 
bay installation, installation and cabling of 
equipment and facilities, and circuit design 
and assembly. 

In addition to these network manage* 
ment functions, SDI also serves as the appli- 
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Panel 1. Abbreviations, Acronyms, and Terms 

ADDS — Attribute Design Database System, an 

alternate name for SDI 
CCP— the Customer Care Platform of AT&T 

Business Communications Services 
ITU— International Telecommunications Union 
OOA— object-oriented approach 
PD H — plesiochronous digital hierarchy 
SDH— synchronous digital hierarchy 
SDI— Service Design and Inventory system 
SONET— synchronous optical network 
STM 1— synchronous transfer mode level 1, the STM 

transport facility with a rate of 155 Mb/s 
TMN— telecommunications management network 
UIM/X*— User Interface Management System for X 

Windows software 



cation interface to the service management and element 
management layers of the TMN. The SDI order manage- 
ment module controls the acceptance and processing of 
requests for changes in the network originating from 
planning organizations, as well as customer service orga- 
nizations. After a request has been processed in the 
network management layer (for example, a circuit has 
been designed and assembled), SDI will then communi- 
cate the design information to the element management 
layer to support physical implementation of the design 
against the appropriate physical network elements. The 
SDI gateway module supports these types of interfaces to 
upstream and downstream applications, as well as inter- 
faces to applications in the network management layer for 
portions of the network that may not be controlled and 
inventoried via the SDI application. 

The final SDI module depicted in Figure 1 is the 
rule management module. This module allows an SDI 
customer to tune the application of SDI to support individ- 
ual processes, services, and technologies. SDI includes 
the following customizable aspects: 

- Service descriptions, supporting routing, design, and 
assembly rules for facilities and circuits providing 
different types of service, as well as acceptable options 
and settings; 

- Processing control schedules and user permissions, 
allowing a customer to outline the specific control steps 
and user permissions for various portions of the design 
and assembly process, as well as permissions manage- 
ment for other modules of SDI; 

- Equipment profiles, allowing templates of different 
equipment configurations to be modeled to support 
automated equipment configuration, as well as valida- 
tion processes; 

- Subnetwork definition, allowing various portions of the 
network to be subdivided based on technology, 
network hierarchy, organization, or other category to 
allow separate definition and control of the target sub- 
networks; and 

- Feature (field definition) control, allowing customiza- 
tion of labels, values, help, and error messages to 
support multiple language delivery. 

SOI Development Methodologies 

The following subsections detail the four devel- 



opment methodologies of the SDI system: object-oriented 
analysis, separation of application-specific and core 
domains, data gateway, and subnetworks. 

Object-oriented Analysis Methodology. To Support 

initial analysis and requirements definition activities, 
members of a team having a wide range of experience 
with existing network provisioning approaches were 
assigned to the SDI project. The team members based 
their initial system specification on an internally gene- 
rated set of scenarios having the following constraints: 

- The specific application domain would be fixed within 
the network management layer of the TMN. 

- The application would handle design and assemble 
functions for all network hierarchical layers and service 
types that might potentially be targeted for support. 

- The application would handle all existing equipment 
technologies that might potentially be targeted for 
support. 

- The application would take into account the complex 
competitive environment in the domain of telecommu- 
nications. Finding an entire network that is owned and 
operated by one telecommunications company or orga- 
nization is becoming increasingly rare. Thus, the appli- 
cation would have to handle the sharing of inventory 
use between multiple network management 
applications. 

This open-ended set of constraints forced a dis* 
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Figure 1. The SDI system Is an exceptionally 
adaptable object-oriented software asset that 
has achieved the integration of a wide range of 
functionality and a high degree of software 
reuse across diverse customer applications. SDI 
supports several application functions within 
the network management layer of the telecom- 
munications management network architecture, 
as shown in the drawing. Within the network 
management layer, SDI acts as the database of 
record for all network-related information. 
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tinctly different approach from that employed for tradi- 
tional one-off software projects in which development is 
often based on detailed requirements defined by a single 
end-user. To maximize software reuse between potential 
application scenarios, the management of the SDI project 
adopted the following two design strategies: 

- Recognize the similarities between scenarios support- 
ing application functions and engineer around them. 

- Separate the similarities found (core aspects) from the 
application-specific aspects in terms of both data and 
functionality. 

To support this strategy for dissecting the appli- 
cation domain, the team decided to take an object- 
oriented approach (OOA) to the analysis. In the initial 
stages of the OOA, a set of primary object classes is 
typically defined. Then, an inheritance hierarchy is 
developed based on "typing" information that allows cate- 
gorization of the class. Initially, typing is rather arbitrary 
and becomes a sort of classification exercise. True typing 
does not emerge until scenarios are found that actually 
result in different attributes and behaviors between 
different object types. 

In the SDI project, the more that was learned 
about the primary target object classes (link, node, 



equipment), the fewer significant differences emerged 
between the class subtypes. Over the course of the analy- 
sis, the class hierarchy became flatter and flatter, or less 
and less specialized. The team slowly discovered that 
within the target application domain (network manage- 
ment), differences in object behavior resulted in different 
relationships between objects rather than fundamental 
differences in the objects themselves. In other words, one 
type of object (such as a particular link type) would be 
defined primarily in terms of the types of objects to which 
it could be related (node types, other link types). The 
primary determinants of these relationships were found 
to be the values of the attributes rather than new or 
different sets of attributes. 

To illustrate this point with the link example, a 
path or aggregate link can be composed of a number of 
component links. The allowable types of component links 
that can constitute this relationship are based on various 
attribute values on both the aggregate and compositional 
links (some examples include bandwidth, mileage, 
restoration priority, transmission media, frame format, 
and line format). A DSO circuit, for example, can only be 
composed of DS1 time slots or other component links 
meeting the attribute requirements of the DSO aggregate 
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Figure 2. Core objects using application-specific rule data 
make SDI an adaptable system. The drawing illustrates the 
separation of application-specific rules from core operations. 
Using circuit provisioning as an example, the provisioning 
process can be depicted as being driven by a customer order 
for a particular type of service, which is defined by various 
attributes describing that particular type. 

link. Although these links differ in the values of their 
attributes, they all contain the same basic attribute set. . 

separation of Domains. Based on the results of the 
preliminary analysis, it was determined that virtually all 
the basic network management application functionality 
could be generalized to a set of primary superordinate 
object classes containing generalized network manage- 
ment operations without the need to develop specialized 
classes (see Figure 2). Specialization was needed, 
however, to support the definition of rules for defining 
which types of objects could be associated with other 
types of objects in the network. Of course, depending on 
the network, these rules could differ from application to 
application based on differences in operations processes, 



services, and equipment technologies. 

To meet the goal of being able to handle these 
different application scenarios flexibly, the team had to 
develop a way to allow the flexible definition of these dif- 
ferences into the application. Toward this end, the team 
began to develop sets of interrelated rules as data struc- 
tures in the database that would support object typing 
(attribute value) information needed to drive the opera- 
tions supporting the core object classes. Whenever a core 
operation is triggered, it accesses the appropriate typing 
information to determine the constraints for establishing 
relationships to other network objects. 

Figure 2 illustrates this separation of application- 
specific rules from core operations. Using circuit provi- 
sioning as an example, the provisioning process can be 
depicted as being driven by a customer order (request) 
for a particular type of service (type of circuit or link 
through the network), which is defined by various attrib- 
utes describing that particular type. 

Generally, the service type (or link type defini- 
tion) is unique to a specific application in both format and 
jargon. Similarly, each telecommunications provider's 
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Figure 3. In the SDI data gateway architecture, 
core data objects, such as service orders, are 
translated into the formats of application- 
specific objects either required or supplied by 
external processes or systems. These external 
objects are either Imported from or exported to 
the externa) systems using the appropriate 
communication module. The gateway supports 
both multiple translation formats and communi- 
cation modules. 
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network is unique in terms of the specific combination of 
vendor s equipment and design strategies. Thus, the link 
or service types and network element types can be 
viewed as application-specific object type definition rules. 

Despite the variations in local type definitions, 
however, all services (as requested by orders) can be 
viewed in terms of their requirements on the fundamental * 
attributes of a transmission network. These attributes, as 
illustrated in Figure 2, include such properties as band : 
width, signaling, line format, and technology. In SDI, 
therefore, the application-specific specialization or typing 
information is captured separately. Then, it is instantiated 
to core objects prior to processing. Thus, specialization is 
achieved not through the development of specialized 
object classes but via the instantiation of specialized 
attribute values against core, generalized super classes. 

The link object class is a good example of using 
modeling generalization and attributes in the formulation 
of object classes and objects. Links represent physical or 
logical connections between two network termination 
points or equipment ports. They can have inventories 
(channels) of available capacity. They can have compo- 
nent links at the same level of the network hierarchy 
(aggregate links) or at different hierarchy levels (which 
provides a mapping between levels). Finally, links have 
such attributes as bandwidth, line formats, technology, 
restoration, and ownership. 

By specifying the appropriate attributes under 



the control of the SDI rules, link objects can be instantiat- 
ed representing, for example, any level of the bandwidth 
hierarchy, any channelization scheme (such as ITU, 
North American, PDH, SONET, SDH), and any technology 
(such as fiber, radio, satellite). By appropriately specify- 
ing the attributes in the SDI rules, therefore, link objects 
can be constructed using the same object class code to 
support the design of a wide range of service types. 

This is a radical departure from many traditional 
system environments. Not only is code not reused, but 
multiple one-off systems are developed to deal with indi- 
vidual service types, bandwidth levels, or technologies. 

SDI applies the same approach to other such gen- 
eralized object classes as equipment, nodes, and orders. 
This insures a high degree of code reuse between applica- 
tions. Furthermore, the rule tables can be defined by 
users without software development, illustrating the flexi- 
bility of the SDI software assets to accommodate changes 
in a user's environment. It also emphasizes the high level 
of control the SDI rule application management process 
places in the hands of a user. 

Data Gateway. The SDI data gateway architecture 
is another example of how the system separates core 
from application-specific functionality. The gateway 
structure is designed to provide a flexible methodology 
for SDI to interface the SDI core capabilities effectively 
with other application-specific systems and processes. 
The gateway separates those parts of the code from the 
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Figure 4. Subnetworks are defined at the link 
and port levels, and subnetwork attributes are 
key to management of the network. This 
drawing illustrates three subnetworks, two of 
which could represent the responsibilities of 
organizational regions. The third subnetwork 
represents a customer's facility between 
locations A and Z. 



core code that may have to change from interface to 
interface. Such separation helps ensure that the changes 
can be made in the least complicated way and with the 
least possible impact on the core portion of the code. 

In the SDI gateway as shown in Figure 3, core 
data objects, such as service orders, are translated into 
the formats of application-specific objects either required 
or supplied by external processes or systems. These 
external objects are either imported from or exported to 
the external systems using the appropriate communica- 
tion module. The gateway supports both multiple transla- 
tion formats and communication modules. This can be as 
simple as formatting a work order and sending it to a 
printer or as complex as a full Q3 interface with 
standards-managed object messages. The gateway con- 
troller is a table-driven process that, for a given transac- 
tion type, will choose the appropriate SDI core object, 
translation format, and communication module, as well as 
the appropriate distribution addresses and frequency 
(immediate or batch at a given time). 

subnetworks. The SDI network model was 
designed to allow a network to be divided into multiple 
subnetworks. This allowed meeting the objective 
requiring the ability to partition the network to support 
complex ownership interdependencies in the network 
management layer. Subnetworks can represent such 
factors as the network responsibilities of various organiza- 
tions, the portions of the network leased from various 



providers, portions of the network dedicated to the use of 
a particular internal or external customer, or the portions 
of the network controlled by various network element 
controllers. Subnetworks can be defined at a granularity 
as specific and as low as port or link using tools in the 
inventory management module. Portions of the network 
can be "members" of more than one subnetwork. 

The subnetwork attribute can be used as a key 
controlling element in many of the rule tables. When 
used with the user group and activity tables, the subnet- 
work attribute can determine, for example, which design- 
er can view (or view and modify) different portions of the 
network. When the subnetwork is used with the gateway 
distribution table, it can cause the gateway to send com- 
mands to the appropriate network element controller or 
to send requests for more leased capacity to the appropri- 
ate telecommunications provider. With the activity 
description table, the subnetwork attribute determines 
such activities as which user groups will be assigned. 

Figure 4 illustrates three subnetworks, two of 
which could represent the responsibilities of organization- . 
al regions. The third subnetwork represents a customer s 
facility between locations A and Z. 

Figure 5 illustrates the application of. subnet- 
works to identify a portion of the network obtained from 
an access provider between nodes A and D and the estab- 
lishment of subnetworks at specific network hierarchy 
levels. For example, the STM 1 SDH network between 
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locations D and G may be the responsibility of a specific 
internal organization. 

The use of the subnetwork attribute in the 
network definition and in the rule tables illustrates 
another capability that SDI places in the hands of a user to 
adapt the SDI software assets to changes in the business 
environment. 

SDI Software and Hardware Architecture 

SDI employs a logically three-tiered client/server 
architecture as depicted in Figure 6. Tier 1 normally 
consists of a workstation containing the user interface, 
some functional modules, and the database interface 
layers. Tier 2 consists of a local file server for the Tier-1 
workstations and printers in the same cluster. The 
database and its server functions are located on a single 
Tier-3 server, also known as the central server. 

Depending on the customer and the customer s 
geographical distribution of offices, two or three of the 
tiers can physically collapse into one. Thus, as shown in 
Figure 6, SDI can range from fully residing on a single 
workstation to a two-tiered client/server model on a local 
area network to a three-tiered architecture on a wide area 
network. This architecture is fully aligned with the AT&T 
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Figure 5. Subnet- 
works are applied to 
various levels of the 
network hierarchy. 
This illustration 
shows the application 
of subnetworks to 
identify a portion of 
the network obtained 
from an access 
provider between 
nodes A and D and 
the establishment of 
subnetworks at 
specific network 
hierarchy levels. The 
STM 1 SDH network 
between locations D 
and G may be the 
responsibility of a 
specific Internal orga- 
nization. 



Business Communications Services (AT&T-BCS) 
Customer Care Platform or CCP, which is currently 
globally deployed. 

The software architecture of SDI, as shown in 
Figure 7, was designed using multiple layers. Where 
appropriate, an object-oriented approach was designed 
within layers to ensure ease of maintenance and porting, 
as well as data encapsulation. 

The physical user-interface layer provides direct 
graphical interface to a user. It separates graphical user 
interface toolkit and platform dependence from the rest of 
the application. This strategy proved useful as SDI was 
ported from the OPEN LOOK* to the Motif* platform, 
only this layer had to be translated. This means that the 
switch to Motif* was made without affecting code other 
than the code at the physical UI layer. A third-party tool, 
the User Interface Management System for X Windows 
software (UIM/X*), is used to design the physical layer. 
The user-interface library layer, which functions as a set 
of C++ class objects and methods, is an object-oriented 
implementation toolkit (an independent window presenta- 
tion). The control logic that drives the physical window 
layer through user-interface library objects resides in the 
abstract user-interface layer. Operations that manage the 
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Figure 6. SOI employs a logically three-tiered client/server 
architecture as depicted In the drawing. Tier 1 normally 
consists of a workstation containing the user interface, 
some functional modules, and the database Interface layers. 
Tier 2 consists of a local file server for the TieM worksta- 
tions and printers In the same cluster. The database and its 
server functions are located on a single Tier-3 server, also 
known as the central server. 



physical window (such as zoom in/out and 
enable/disable buttons) are implemented in this layer. 
Finally, application-layer objects requiring visual presenta- 
tion are grouped in the presentation layer. 

The software architecture that maps the object- 
based modules into the relational database is illustrated in 
Figure 8. This drawing also depicts key characteristics of 
the SDI software architecture, as well as aspects of the 
modeling and development tools employed. The functional 
object-oriented modules 1 , programmed in C++, interface 
to the ORACLE?* relational database management system 
through an object-oriented database interface layer, 
which is code generated using the specification-driven 
code generator MetaTool™. This layer provides the func- 



tional modules' independence from the database. 

SDI object modeling drove the definition of the 
table structures in the relational database. Using Rum- 
baugh's techniques 1 , the tables closely resemble the 
objects themselves. Denormalizing some tables in the 
database leads to improved performance for the- database 
calls. Tuning the database for performance has been an 
important project activity. 

To further improve performance and to separate 
the functional code from the details of the database real- 
ization, stored programs within the ORACLE system have 
also been employed. This is particularly important in light 
of the scaleable SDI hardware architecture depicted in 
Figure 6 in which the stored procedures reduce the 
amount of data that must be transmitted on the wide area 
networks between the central server and the clients. 

SDI uses several third-party tools and libraries in 
its design. AT&T standard components libraries are a key 
part of SDI design. In addition, the use of AT&T BaseWorX™ 
system components, third-party map and table widgets, 
as well as hypertext have helped reduce the time 
required for development of the SDI system. 
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Figure 7. The software architecture of SDI, as shown In the 
Chart* was designed using multiple layers. Where appropri- 
ate, an object-oriented approach was designed within layers 
to ensure ease of maintenance and porting, as well as data 
encapsulation. 



SOI Deployment Activities 

The deployment of the SDI system is based on a 
particular software release and includes the following 
three major activities: 

- Characterization of the user's environment to obtain 
the information necessary to populate the appropriate 
tables and rules, ensuring that the core components 
will meet environmental needs; 

- Assistance with the initial database population; and 

- Identification and development of the necessary 
application-specific components. 

With the rule-based structure of the SDI system, 
the capabilities required by a customer are partially 
realized both by the functionality of the code and by the 
populated rules. System testing of the code releases, 
therefore, only partially ensures that the customers 
requirements will be realized. 

Thus, a dual-cycle testing strategy has evolved 
from the SDI project. This strategy consists of through- 
system code testing followed by testing of the rules 
within the environment of the tested code. The rule 
testing generally takes the form of a regression of a key 



subset of the system tests combined with scenario testing 
based on specific customer application processes. After 
the entire testing cycle is completed, the system is 
deployed having an initial set of customer rules. 

Rule management tools are available to enable an 
application administrator to modify the tables and rules to 
accommodate most changes in their environment, such 
as new services, technologies, and organizational respon- 
sibilities. To ensure the integrity of the rule data, 
however, the administrator must establish a test data envi- 
ronment for basic scenario testing before the introduction 
of new data structures into the operational environment. 

Specific Deployment Activities. Currently, SDI has 

been deployed to four customers, including those in both 
the Spanish and English environments. The first four 
applications represent a wide variety of network configu- 
rations, service types, organizational structures, and work 
flows. In addition, the following basic technologies 
addressed in the customer networks varied widely: 

- Transport capacity design and leased line circuit 
design for a network based on E5 fiber and E4 radio 
technologies; 

- Trunk networks between customer PBXs, access 
switches, and backbone switches having leased 
transport at the El, E3, or E4 bandwidth levels; and 

- Transport capacity design involving an SDH-based 
backbone network initially supporting a switched trunk 
network but evolving to a broad set of voice and data 
services. 

In addition to these fundamental differences in 
deployed technologies, the operations processes and user 
permissions management have also differed widely 
between the initial SDI customers. Despite the diverse 
nature of these applications, SDI has achieved virtually 
100-percent software reuse across the deployments, dis- 
counting the software enhancements between releases 
for a product early in its development cycle. These 
achievements are a direct result of the design objectives 
adopted at the beginning of the project. 

Conclusion 

The definition of generalized, attribute-based 
object classes in SDI enables the same code to be applied 
to a wide range of user scenarios. To operate, these gen- 
eralized object classes are specialized via the instantiation 
of attributes retrieved from user-populated rule tables. 
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Figure 8. This drawing shows the mapping of objects In SOI 
to relational database tables. It also depicts key characteris- 
tics of the SDI software architecture, as well as aspects of 
the modeling and development tools employed. The function- 
al object-oriented modules, programmed in C++, interface to 

Thus, not only is the same code reused, but the operation 
of the system can be configured by a user without addi- 
tional code development This arrangement reduces the 
time and expenditure necessary to customize SDI to meet 
application requirements, thereby reducing the time and 
cost required to introduce new technologies, services, 
and user-defined processes and permissions. 

The adaptability of the object-oriented attribute 
and rule-based software has many user advantages in 
todays competitive and rapidly evolving telecommunica- 
tions environment. The maintenance and generation of 
quality rules, however, is a responsibility that requires a 
thorough understanding of the user operational environ- 
ment and SDI rule structures, as well as the discipline to 
test and verify the operation of the rules as the environ- 
mental needs evolve. 
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(54) A method for implementing a managed object in a network management system 



(57) The invention relates to a method for imple- 
menting a managed object in a subsystem of a man- 
aged system in a management network with at least 
one managing system and at least one managed sys- 
tem, for telecom or open systems, said managed sys- 
tem consisting of subsystems forming each a part of the 
managed system including one or more managed 
objects. 

The managed objects are implemented in the sub- 
system, uncoordinatedly with respect to other subsys- 
tems, in such a way that they can be connected to and 
transmit messages to other objects in other subsys- 
tems, and without knowing the type of objects in the 
other subsystems. This is obtained by designing a first 
object (330) for co-operation with an abstract object 
(332) defining an interface consisting of unimplemented 
methods, which may be called by the first object, and 
letting, at later design of a second object (334) unknown 
to said first object and intended to co-operate with the 
first object, the other object inherit the abstract object 
and implement the inherited methods, so that the first 
object at co-operation with the second object will con- 
sider it as being of said abstract type. 
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Description 

Technical field 

The present invention relates to a method for imple- 
menting a managed object in a management network 
with at least one managing system and at least one 
managed system, for telecom or open systems, said 
managed system consisting of subsystems forming 
each a part of the managed system including one or 
more managed objects. 

With a "management network with at least one 
managing system and at least one managed system" is 
meant that the management network can include at 
least one managing system which can manage one or 
more managed systems, which likewise can form part of 
the management network. 

With an open system is meant a system of the kind, 
which is defined in Reference Model of Open Systems 
Interconnection (OSI) for CCiTT Applications, Rec. 
X.200. 

To perform management activities in a manage- 
ment domain there must be at least one manager which 
is responsible for the management of the resources. A 
resource is something which includes concepts and 
ability of the domain. An example of a domain is a tele- 
com network, where the resources are switches, trunks 
etc. and management units are e.g. operator tools and 
managing systems for the network. 

For operation of telephone networks each individ- 
ual company has used a.number of different systems for 
operation and maintenance. CCITT has developed a 
standard model for operation and maintenance in tele- 
phone networks, called TMN (Telecommunication Man- 
agement Networks). The basic principle of TMN is to 
indicate an organized network structure, which admits 
connection of various managing systems to telecom 
equipment. This is achieved by use of standardized pro- 
tocols and interfaces. The telephone companies and 
other operators will require that future telecom networks 
are adapted to TMN. 

CCITT has a recommendation for this under devel- 
opment, the M.3000-serie. 

TMN considers all network nodes as network ele- 
ments (NE). These network elements are made as tele- 
phone switches and transmission or transport network 
products. 

The functional structure of TMN comprises 

management functions (OSF, Operations Support 
Functions), which manage application programs 
available for users, such as management functions 
for "Business Management" and service and net- 
work administration; 

data communication functions (DCF; Data Commu- 
nications Functions), which manage data communi- 
cation between the managing systems OSS and 
the managed systems NE; 
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mediation functions (MF, Mediation Functions), 
which convert information (between e.g. managed 
objects), manage data, concentrate, reduce and 
edit, make decisions relating to e.g. threshold limits 
5 and store data, which identify equipment and net- 
works; 

network element functions (NEF, Network Element 
Functions), which manage telecom processes as 
switching functions and transmission, and take part 

10 in management processes for telecommunication, 
as fault localisation and protection connections; 
- functions for interface adaption (QAF, Q-Adapter 
Functions), which perform conversion of interfaces 
from non standard to standard; 

15 - work station functions (WSF, Work Station Func- 
tions), which constitute the user terminals of TMN, 
show information and assist management techni- 
cians to manage the network. 

20 TMN also includes an interface, called 03. 03 is 
besides being a communication protocol also an infor- 
mation model, which comprises data schemes, opera- 
tions and notifications. The exact details of the Q3 
interface and its protocols appear from the CCITT rec- 

25 ommendations Q961 and Q962. 

TMN considers all physical and logical objects as 
managed objects, which in TMN are referred to. as MO 
(Managed Objects), a denomination which will be used 
alternately also here henceforth. Managed objects are 

30 data images of such physical or logical resources as 
wires, circuits, signal terminals, transmission routes, 
events logs, alarm reports etc.. 

A specific relationship occurs between a resource 
and a managed object. A resource can be related to one 

35 or more MO or none at all. On the other hand an MO 
can be related to one or more resources or none at all. 
This relationship is important if an MO is affected by 
some form of operation or maintenance activity. An MO 
must not be removed before the functions to which it is 

40 subordinated have themselves been removed. This 
information model is based upon object orientation and 
the relation concept. 

The managing system (OSS- Operation Support 
system) treats network elements and subordinated 

45 managing systems as a collection of managed objects 
in an imagined data base MIB (Management Informa- 
tion Base). These managed objects are constituted by 
instances of an MO class, such as a number of signal 
terminals of the same type. Each terminal will thus con- 
so stitute an instance of the class signal terminals. 

In TMN there also exists the concept MIM (Man- 
agement Information Model), which refers collectively to 
all information related to managed objects. MIM is a 
model of all attributes, relations, operations and notrf ica- 

55 tions referable to managed objects. To be able to search 
for MO-instances a management information tree MIT 
(Management Information Tree) is used. This tree struc- 
ture starts in the network and indicates network ele- 
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ments and subscribers or equipment. 

For operation and maintenance each separate unit 
or resource, about which information is required, or the 
operation of which is influenced from the outside of the 
system, is represented by a managed object. Each 
information exchange referable to the management of 
operations or units, which must be influenced or which 
must report something (such as set up of data, assign- 
ment of name, or management of alarms) is done in the 
form of operations on, or notes from managed objects. 

A managed object includes attributes and can also 
have a relation to other managed objects. A number of 
different operations can be directed towards a managed 
object and events can be generated by such objects. 

Below an account of deficiencies of TMN will be 
given. 

Network elements and subordinated managing sys- 
tems are managed by a managing system by means of 
operations towards the managed objects in the man- 
aged systems and supervision of notifications transmit- 
ted by the managed system. 

Allowed operations towards managed objects in the 
managed system are determined by an information 
model of the managed system, together with the notifi- 
cations, which can be transmitted. The information 
model states: 

which classes of managed objects that are defined, 
which operations the managed objects in these 
classes accept, 

which notifications that the managed objects are 
expected to transmit, 

how many instances that can be created or 
removed, in each class of managed objects, 
dependences between managed objects, e.g. that 
one managed object requires existence of another 
one, 

dependences in a managed object, e.g. that a spe- 
cific attribute value of one attribute is only allowed if 
another attribute is set to a specific value or if the 
managed object only can be removed if it is in a 
specific state, 

the purpose and intention with managed objects 
and their notifications. 

To be meaningful the managing system must know 
the information model of the managed system. This is in 
TMN called "shared management knowledge". 

At a change of the information model the manage- 
ment model must be updated in accordance with this 
change. In conventional systems these changes are 
made by: 

Definition of the new information model. This is 
made by specifications for managed objects written 
as GDMO/ASN.1 templates (GDMO - Guidelines 
for the Definition of Managed Objects according to 
CCITT rec. X.722 ISO/IEC 10165-4) and ER-dia- 
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grams (Entity- Relationship diagrams) for the man- 
aged objects. The specifications for the managed 
objects state formally (machine readable) syntax 
(e.g. operations and notifications) for the managed 
5 object. 

All other parts of the information model, as depend- 
ences, the number of instances etc., are stated infor- 
mally as comments in natural language. 

10 

Implementation and verification of the new informa- 
tion model in the managing system and the man- 
aged system. 

Confirmation that the managing system and the 
is managed systems are adapted to the same infor- 
mation model by performing accepted test 
sequences. 

Updating of the network consisting of the managing 
system and the managed system with this new ver- 
20 sion of the information model. 

That just mentioned above results in a number of 
problems: 

25 Firstly, the development of managing systems and 
managed systems must be coordinated, which 
leads to higher development costs and/or a delayed . 
introduction of new services on the market. 
Secondly, the absence of formalism with respect to 

30 the specifications of the managed systems, makes 
implementation, verification and acceptance of both 
managing system and managed systems to a diffi- 
cult and time demanding task, since the interpreta- 
tion of the specifications is open to discussion. 

35 Thirdly, updating of networks must be planned and 
carried out carefully, as there are dependences 
between different versions of the managing sys- 
tems and managed systems. This involves a 
delayed introduction of new services in the network. 

40 

The purpose of management according to the TMN 
model is to be a framework for standardization of man- 
agement for telecom networks and open systems. The 
management structure strongly influences the manage- 
rs ment paradigm for new system architectures. There are 
strong reasons to assume the management paradigm 
according to the TMN model for the whole management 
and not only for domains subjected to standardization. 
The main reason for this is that it is desirable to be able 
so to develop and design management functions in a uni- 
form way. 

Summary of the invention 

55 It is a purpose of the invention to design a managed 
object, which should be able to communicate with 
unknown future objects. It should be possible for the 
original object to be related to and to co-operate with an 



5 



EP 0 817 422 A2 



6 



unknown object without modification, or even reloading 
of the original object 

Said purpose is attained by the method defined by 
way of introduction being characterized in that the man- 
aged objects are implemented in the subsystem, unco- 
ordinatedly with respect to other subsystems, in a way 
that they can be connected to and transmit messages to 
other objects in other subsystems, and without knowing 
the type of objects in the other subsystems, by design- 
ing a first object for co-operation with an abstract object 
defining an interface consisting of unimplemented 
methods, which may be called by the first object, and 
having, at later design of a second object unknown to 
said first object and intended to co-operate with the first 
object, the second object to inherit the abstract object 
and implement the inherited methods, so that the first 
object at co-operation with the second object will con- 
sider it as being of said abstract type. 

Advantageous embodiments of the invention have 
obtained the characterizing features stated in the 
respective dependent claims. 

Description of the drawings. 

A number of embodiments of the invention will now 
be described below in greater detail with reference to 
the enclosed drawings, on which 

Figures 1-9 in block diagrams illustrate problems, 
which can appear at the use of technology accord- 
ing to the state of the art in connection with the 
design of managing systems, where 
Figures 1-4 concern problems, which can appear in 
connection with reuse of library components in the 
managed objects in managed systems, 
Figures 5 and 6 refer to problems, which can 
appear at the implementation of a managed system 
in a layered system architecture, 
Figures 7-10 illustrate how the problems according 
to Figures 1 -6 can be generally solved by design of 
a specific type of object, which should be able to co- 
operate with unknown future managed objects, 
Figures 11-14 specify design of objects according 
to Figures 10-14, the object type being assumed to 
belong to a platform system, 
Figures 15-20 show the implementation in the pro- 
gram code C++ of dependences between the 
designed objects according to Figures 11-14. 

Description of embodiments 

A managed system consists of several subsystems, 
more exactly a system platform and a number of appli- 
cations. According to the invention these subsystems 
are developed uncoordinatedly and are loaded sepa- 
rately. 

At the development of an application - or a system 
platform - there are libraries with reusable components. 



These components should be incorporated and com- 
bined in different ways in the different subsystems. 

The two different problems described above have 
certain properties in common. There are system com- 

5 ponents, which are developed uncoordinatedly, but still 
there are dependences between the components. To 
keep such dependences it is necessary that the compo- 
nents should be able to communicate with other compo- 
nents which are separately developed and even loaded. 

w The design process described below in greater 
detail is usable in two different contexts with similar 
problems. 

The first problem refers to reuse of library compo- 
nents. 

is At design of a managed system there are libraries 
with reusable components, which can be incorporated 
in the objects of the managed system. As is illustrated in 
Figure 1 there are first a main library 260 including com- 
ponents with basic functionality, such as MOstateCom- 

20 ponent 262 and WorkingStateComponent 264. These 
components include state attributes common to many 
different types of managed objects. The functionality of 
these basic components is reused by other components 
with a more specialized functionality. In the traffic man- 

25 agement library 266 there is e.g. a StatePropagation- 
Component 268, which has the ability to transfer state 
transitions in MOstateComponent 262 to the related 
dependent object 270. 

It should be emphasized that components as well 

30 as the managed objects are supposed to be imple- 
mented in an object oriented language. Both the com- 
ponents and the managed objects are thus really 
objects. But the components can not exist as identifiable 
objects by themselves in an application. They can only 

35 form a part of managed objects. 

A straightforward way to implement components, 
which depend on other basic components, eg. the com- 
ponents in the fault handling and the traffic manage- 
ment libraries in Figure 1, is to include the basic 

40 components either by heritage or aggregating. This 
causes however many problems. This depends upon 
the fact that several components, e.g. FaultHandling- 
Component 272 and ResourceManagementCompo- 
nent 274, which inherit or aggregate the same basic 

45 component e.g. MOstateComponent 262, can be 
included in the same managed object-Route 276, com- 
pare Figure 2. This implies that there will be several 
copies of the basic component in the managed object, 
which will cause consistency problems if the basic corn- 
so ponent includes data, which is visible external to the 
components. Data of MOstateComponent should in 
other words be available for another functionality in the 
managed object than those components in which 
MOstateComponent is included. 

55 There is a way to avoid the problem described 
above. 

MOstateComponent should not be inherited or 
aggregated in components which depend on this com- 
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ponent. Instead the dependent components should 
.include reference attributes to MOstateComponent. 
Thus the latter will be a component of its own in those 
objects in which it is included. Components which need 
to access MOstateComponent will then each include a 
reference to the same instance of the MO-state compo- 
nent, compare Figure 3. 

As has been mentioned earlier a component, such 
as ResourceManagementComponent 274 and Fault- 
HandlingComponent 272, can include a functionality 
which is triggered by state changes in MOstateCompo- 
nent 262. The latter must therefore be able to transmit 
state change messages to other components. One 
problem is however that the receivers of these mes- 
sages are unknown at the design of MOstateCompo- 
nent. MOstateComponent 262 must in some way be 
able to communicate, cf. arrows 280, 282, with an arbi- 
trary later appearing component, compare Figure 4. 

The second problem refers to a layered system 
architecture. 

A managed system can be implemented in a lay- 
ered-architecture. More exactly, there are system plat- 
forms with basic functions, which can be reused by 
different applications, compare Figure 5. The system 
platform 290 i.a. includes different kinds of common tel- 
ecom services. The application can thus delegate many 
tasks to the system platform. The system platform 290 
and the applications 292 are loaded separately. It must 
be possible to load an application and link it to the sys- 
tem platform without reloading the platform. 

Both the system'platform 290 and the applications 
292 include managed objects. The objects 294 and 296 
in the platform 290 can e.g. represent resources, as 
switches, transmission routes, trunks etc. The objects 
298,300 and 302,304 in the applications 292.1 resp 
292.2 can be related to and co-operate with the 
resources in the system platform, compare Figure 6. An 
object in an application can delegate some tasks to an 
object in the system platform. Objects in the applica- 
tions may thus depend on related objects in the system 
platform to be able to work. As the system platform is 
known at the development of an application it is no prob- 
lem to design the objects in the applications for commu- 
nicating with the objects in the system platform. As has 
been mentioned earlier the objects in the applications 
can however be dependent on the objects in the system 
platform. This implies that objects in the system plat- 
form should be able to transfer state changes, as has 
been described earlier above, to objects in the applica- 
tions. This implies that objects in the platform should be 
able to be related to and take initiative to calling objects, 
which are unknown at the design of the platform sys- 
tem. 

Above two cases with similar problems have been 
described. Here will now follow a description of how 
these problems can be solved. 

More exactly, the real problem in each of the two 
cases is to design an object, which should be able to 



communicate with unknown future objects. It must be 
possible for the original object to be related to and to co- 
operate with an unknown object without modification, or 
even reloading of the original object. 

5 This problem can be solved with the design princi- 
ple illustrated in Figure 7. The original object 330 is 
designed to co-operate with an abstract object 332. The 
abstract object defines an interface consisting of unim- 
plemented methods. These are the methods, which can 

w be called by the original object. At the design of an 
object 334 designated to co-operate with the original 
object it must inherit the abstract object 332 and imple- 
ment its inherited methods. At the co-operation with an 
unknown type of object the original object 330 will con- 

is sider this as being said abstract type 332. At call of a 
method defined in the interface of the abstract object 
332 the call will be delegated to implementation in the 
real object 330 via late binding. 

Avoidance of reloading of the original object at load- 

20 ing of the future objects is achieved by dynamic linking. 
Figure 8 illustrates how the just described design 
can be used for the design of basic library components. 
MOstateComponent 340 is designed to communicate 
with objects, which inherit an abstract object: 

25 MOstateSubscriber 342. This abstract object defines 
methods called by MOstateComponent when a state 
change occurs. If a component should subscribe to 
state changes in MOstateComponent, it must inherit 
MOstateSubscriber 342 and implement the answer to \. 

30 the respective state transition notifications. The sub- 
scribing component must of course also state itself as a 
subscriber to MOstateComponent. 

The principles of design described with reference to 
Figure 7 can also be used for designing objects in a sys- 

35 tern platform to co-operate with application specific 
objects. This is illustrated in Figure 9, where object 
PlatformObjectl 350 is designed to co-operate with 
object 352 in application system 354. An object in an 
application, which should co-operate with the object 

40 Platformobjectl 350 must inherit the abstract object 
Interfaceobject 356. Further there is a data base rela- 
tionship between PlatformObjectl 350 and InterfaceOb- 
ject 356. This implies that the objects which inherit 
InterfaceObject 356 can set up relations with 

45 PlatformObjectl 350. To make it possible to load appli- 
cations without reloading of the system platform 
dynamic linking is used. 

Often an object in an application system is state 
dependent of another object in the system platform. 

so This design makes it possible to implement such state 
dependences in essentially the same way as for objects 
which are known to each other when they are imple- 
mented, as will be described in greater detail further 
below. 

55 Dependences between uncoordinated objects can 
be specified and implemented in essentially the same 
way as between coordinated objects, which has been 
described earlier above. Here the same examples will 
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be used to show the design and implementation of 
dependences between uncoordinated objects. It is how- 
ever assumed here that the object type ResourceB 
belongs to a platform system. Thus, with reference to 
Figure 10, various kinds of objects in various application 
systems can be related to and co-operate with the 
object ResourceB 370. The object type ResourceB 370 
is related to UserObject 372 via a data base relation- 
ship. ResourceA 374 inherits UserObject 372 to be able 
to be related to ResourceB 370. In the following it will be 
shown how these objects are specified and imple- 
mented. The same pseudo syntax as above will be 
used. 

The specification of the object ResourceB is found 
in Figure 11. The specification includes two state 
attributes: admState and opState, a method to allocate 
instances of ResourceB and a precondition which 
states that to enable erase of a ResourceB object it 
must be locked. This is essentially the same as earlier. 
The only difference is that in this example ResourceB is 
related to UserObject instead of ResourceA. The rela- 
tion is established via a reference attribute userRef, line 
6. 

In Figure 12 the object UserObject is specified. It 
includes the state attribute admState. It can however be 
noted that this attribute is specified as being purely vir- 
tual, line 19. This implies that the UserObject in fact will 
not include the attribute admState. The interface of Use- 
rObject will however include unimplemented write and 
read methods for this attribute. The real implementation 
of these virtual methods will appear in the respective 
subtypes of UserObject. Besides there are another 
attribute resourceBstate, which is assumed to keep the 
value of opState in the related object ResourceB. Fur- 
ther, the UserObject has a reference attribute Bref, 
which is used to establish relations with objects of the 
type resourceB, line 21. 

A dependence scheme, which specifies end condi- 
tions, including both the object UserObject and the 
object ResourceB is found in Figure 13. There is an end 
condition, lines 29-31, which states that admState of 
UserObject depends on admState in ResourceB in such 
a way that an object UserObject can not be locked up if 
the related object ResourceB is locked. 

In Figure 13 it is further specified that when a value 
of opState in an object ResourceB is changed, the new 
value should be propagated to the related instance of 
UserObject. In Figure 13 there is no end condition spec- 
ified which relates to opState, it is only stated that 
changes of opState in ResourceB should be propa- 
gated to the attribute resourceBstate in UserObject, 
lines 36 and 37. This implies that all subtypes of Use- 
rObject are not necessarily opState dependent on 
ResourceB, but each subtype of UserObject can man- 
age the opState dependence of ResourceB in its own 
way. 

In Figure 14 the specification of ResourceA is 
shown. ResourceA is specified as being a subtype of 



UserObject (line 41). This implies that ResourceA inher- 
its the attributes, methods, conditions and the propaga- 
tions in UserObject. All the purely virtual specifications 
in UserObject must be specified and implemented in 

s ResourceA. As appears from Figure 7 the value of 
opState in ResourceA is derived from the attributes 
internalOpState and resourceBstate (which is inherited 
from UserObject), lines 46-49. 

As has been mentioned earlier the implementation 

w is essentially the same as when the objects belong to 
the same system. The difference is that a certain part of 
the functionality of the dependent object which uses 
ResourceB is implemented in UserObject. As earlier the 
code can automatically be generated from the specif ica- 

is tions by a compiler. The declaration file which is gener- 
ated from the specification of UserObject in Figure 12 is 
found in Figure 15. 

The method checkConsistency in UserObject 
checks the dependence between the admState 

20 attributes, which are stated in the dependence scheme 
in Figure 13. The implementation of this method is 
shown in Figure 16. To check this condition the value of 
admState in UserObject must be read. This explains 
why there must be a purely virtual specification of adm- 

25 State in UserObject, even if this attribute is not really 
included in UserObject. 

The declaration file which is generated by the spec- 
ification of ResourceB in Figure 1 1 is found in Figure 17. 
The implementation of the method propagateOpstate is 

30 however somewhat different, compare Figure 8. The 
new value is propagated to the attribute ResourceB- 
state in the related userObject instance. The admState 
dependence between UserObject and ResourceB must 
be checked at updating of the object ResourceB as well 

35 as at updating of UserObject instances. Therefore, this 
condition is implemented in the method checkConsist- 
ency in ResourceB. 

Figure 9 shows the declaration file, which is gener- 
ated from the specification of ResourceA. The opState 

40 dependence of ResourceB is implemented by deriva- 
tion of the value of opState from resourceBstate and 
internalOpState, compare Figure 20. 

The advantages of the above described are the fol- 
lowing. 

45 Dependences and co-operation between uncoordi- 
nated objects can be specified and implemented in the 
same way as dependences between objects in the 
same subsystem. This implies that they are visible to 
and can be interpreted by a managing system. 

so The above illustrated process for maintenance of 
dependences between uncoordinated objects in a con- 
trolled and visible way facilitates implementation of a 
determinable management model in a layered architec- 
ture. 

55 The degree of reuseability of the library compo- 
nents can be improved by a high degree of flexibility 
when combinations of components are concerned. 
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Claims 

1 . A method for implementing a managed object in a 
subsystem of a managed system in a management 
network with at least one managing system and at s 
least one managed system, for telecom or open 
systems, said managed system consisting of sub- 
systems forming each a part of the managed sys- 
tem including one or more managed objects, 
characterized by implementing the managed w 
objects in the subsystem, uncoordinated! y with 
respect to other subsystems, in such a way that 
they can be connected to and transmit messages to 
other objects in other subsystems, and without 
knowing the type of objects in the other subsys- is 
terns, by designing a first object (330) for co-opera- 
tion with an abstract object (332) defining an 
interface consisting of unimplemented methods, 
which may be called by the first object, and letting, 

at later design of a second object (334) unknown to 20 
said first object and intended to co-operate with the 
first object, the other object inherit the abstract 
object and implement the inherited methods, so 
that the first object at co-operation with the second 
object will consider it as being of said abstract type. 25 

2. A method according to claim 1, characterized by 
delegating, at call of a method defined in the inter- 
face of the abstract object, the call to the implemen- 
tation in the real object by means of late binding. 30 

3. A method according to claims 1 or 2, characterized 
by reloading, in case of loading of said second 
object, said first object in the managed system by 
means of dynamic linking between the respective 35 
subsystems. 

4. A method according to any of claims 1 -3, character- 
ized by locating said first and second objects in first 
and second subsystems, respectively. 40 

5. A method according to claim 4, characterized by 
using dynamic linking to enable loading in the man- 
aged system of said second subsystem without 
reloading of said first subsystem. , 45 



55 



EP 0 81 7 422 A2 



Application System A 



Application 
Object 1 



298 



Application 
Object 2 



A. 



Fig. 6 

- -292.1 
292.2- 

302- 



Application System B 


Application 




Application 




- Object 3 




Object 4 




/ 







\ 



\ 



/ 



/ 



/ 



interaction and 
relations 

V 

A 



/ 



/ 



System Platform V 

/ \ 

t \ 



29k 



Platform 
Object 1 

3= 



Platform 
Object 2 



^290 



296 




1 



EP 0 817 422 A2 



Fig.8 



Basic Support Library 



MOstate 
Component 
5 



340 



Messages 



MOstate 
Subscriber 
i ) 



T 



342 
isA 



Traffic Support Liiirary i 

\ i 


State 

Propagation 
Component 




Resource 

Management 

Component 





Fig. 9 



354- 



Application System 



352- 



AppJicatioh 
Object 1 1 



isA 



Messages 



System Platform 



356- 



JL 



Interface 
Object 



Messages 



Datab. 
rel. 



Platform 
Object 1 



— r 

350 



Fig. 10 



Application System 



Resource A 



374 



isA 




System Platform 



userRef 



-372 




EP 0 817 422 A2 



Fig. 11 



1 OBJECT TYPE ResourceB IS 

2 ATTRIBUTES 

3 key : KeyType; 

4 admState : Administrat iveState ; 

5 op St ate : OperationalState; 

6 userRef : REFERENCE TO UserObject 

INVERSE OF Bref; 

7 PRIMARY KEY key; 
8 

9 METHODS 

10 allocateO RETURNS Boolean; 
11 

12 PRE-CONDITIONS 

13 deleteObject () ONLY IF 
admState = locked; 

14 

15 PARTY TO ResourceAndUser ; 

16END; 
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170BJECT TYPE UserObject IS 

18 ATTRIBUTES 

19 admState : Administrat iveSt at e , 

PURE VIRTUAL; 

20 resourceBstate : OperationalState; 

21 Bref : REFERENCE TO ResourceB 

INVERSE OF UserRef; 

22 

23 PARTY TO ResourceAndUser; 
24END; 
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250 EPENOENC Y SCHEMA ResourceAndUser IS 

26 FOR ALL UserOb j e ct ( a ) , ResourceB (b ) ; 

27 RELATIONS a.Bref = b; 
28 

29 POST-CONDITIONS 

30 NOT (a.admState = unlocked AND 

31 b.admState = locked) 

32 RULES 

33 WHEN COMMIT THEN CHECK CONSISTENCY; 
34 

35 PROPAGATIONS 

36 WHEN b.opState = NewValue 

37 THEN CONCLUDE a . resourceBstate=NewValue ; 
38 

39END; 
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400BJECT TYPE ResourceA IS 


41 


BASE. UserObject ; 


42 




43 


ATTRIBUTES 


44 


key : Key Type ; 


45 


admState : AdministrativeState ; 


46 


OERIVED opState = IF ( InternalOpState=disabled OR 


47 


resourceBstate=disabled) 


48 


THEN disabled 


49 


ELSE enabled; 


50 




51 


internalOpState : OperationalState PRIVATE; 


52 




53 


PRIMARY KEY key; 


54 




55 


METHODS 


56 


allocate() RETURNS Boolean; 


57 




58 


PRE-CONDITIONS 


59 


deleteOblect ( ) ONLY IF admState = locked; 


60 




61 


POST-CONDITIONS 


62 


NOT (admState = unlocked ANO Bref = NULL) ; 


63 


64END; 
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65 ifndef _User0b j ect_hh_ 

66 define _User0b j ect_hh_ 
67 

68 include <Predef inedTypes . hh> 

69 include "MOstat eTy pes . hh " 

70- 

71class ResourceB 
72 

73// OBJECT Type Userobject 
74 

75class Userobject 
76( 

77public 

78 static UserObject* open (Mode , const 

79 KeyTypeS, DbTransact ion * transaction: 
NULL) ; 

80 virtual delet eObj ect ( ) =0; 

81 virtual Boolean checkConsist ency 
( ErrorMessageS) ; 

82 

83 virtual Administrat iveSt at e 
getAdmState ( ) =0; 

84 virtual void setAdmState 
(const AdministrativeSt ate) == ; 

85 OperationalState getResourceBst ate ( ) ; 

86 setResourceBstate (const 
OperationalState) ; 

87 ResourceB* getBrefO; 

88 void setBref ( ResourceB* ) ; 
89 

90privat e : 

91 

92 

93) ; 
94 

95 endif 
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Fig. 16 



97 include "UserOb j ect . hh" 

98 include "ResourceB . hh" 
99 

100//////////////////// 
101// 

102// User-Object: METHOD checkConsistency 

103// 

104 

105Boolean UserObject: : checkConsistency ( 
ErrorMessage& message) 

106( 

107 Boolean flag = true; 
108 

109 flag = ! (getAdmState ( ) unlocked && 

110 getBref ( ) ->get admSt ate ( ) = = loc ked ) ; 

111 if ( !flag) ( 

112 createErrorMessage ( 1 , message) ; 

113 ) 

114 return flag; 
115) 

116 
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Fig. 17 

117 ifndef ResourceB hh_ 

118 define 27* esourceB _^ n _ 
119 

120 include <Predef inedTy pes . hh> 

121 include "MOst ateTypes . hh " 
122 

123class UserObject; 
124 

125// OBJECT TYPE ResourceB 
126 

127class ResourceB 
128( 

129public 

130 void deletob j ect ( ) ; 
131 

132 void deleteObject () ; 

133 Boolean allocate(); 

134 virtual Boolean checkConsistency 
( ErrorMessage&) ; 

135 

136 KeyType getKey ( ) ; 

137 AdministrativeState getAdmStat e ( ) ; 

138 void setAdmState (const 
AdministrativeState) ; 

139 OperationalState getOpState( ) ; 

140 void setOpState (const OperationalState); 

141 UserObject* getUserRef ( ) ; 

142 void setUserRef (UserObject*) ; 
143 

144privat e 

145 void propagateOpState 
(const OperationalState) ; 

146 void opState (const OperationalState) ; 

147 

148 

149) ; 

150 

151 endif 
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Fig. 18 

153 include "ResourceB . hh" 

154 include "UserOb j ect . hh" 
155 

156////////////////////// 
157// 

158// ResourceB: METHOD setOpState 

159// 

160 

161void ResourceB: : setOpSt at e ( 

const Operat ionalSt ate newValue) 

162( 

163 OperationalState oldValue = getOpSt ate ( ) ; 
164 

165 opState (newValue) ; 

166 if (newValue != oldValue) 

167 ( 

168 propagateOpState (newValue) ; 

169 ) 
170) 
171 

172///////////////////////// 
173// 

174// ResourceB: METHOD PropagateOpState 

175// 

176 

177void ResourceB: : propagateOpSt at e ( 

const OperationalState newValue) 

178( 

179 getUserRef()->resourceBstate (newValue) 

180) 

181 
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Fig. 19 

182 ifndef _ResourceA_hh_ 

183 define _ResourceA_hh_ 
184 

185 include <Predef inedTypes . hh> 

186 include "UserOb j ect . hh " 
187 

188// OBJECT TYPE ResourceA 
189 

190class ResourceA : public UserObject 
191( 

192public 

193 static ResourceA* open(Mode, 

194 const KeyTypeS, DbTransaction* 
transaction=NULL) ; 

195 void deleteObject (); 

196 virtual Boolean checkConsist ency 
( ErrorMessageS) ; 

197 

198 Boolean allocate(); 
199 

200 KeyType getKey ( ) ; 

201 AdministrativeState getAdmSt ate ( ) ; 

202 void setAdmState (const 
AdministrativeState) ; 

203 OperationalState getOpSt ate (.) ; 
204 

205private 

206 OperationalState get InternalOpSt ate ( ) ; 

207 void setlnternalOpState (const 
OperationalState) ; 

208 

209 

210); 

211 

212 endif 
213 
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214 include "ResourceA . hh" 
215. 

216///////////////////// 
217// 

218// ResourceA: METHOD getOpState 

219// 

220 

2210perationalState ResourceA: : getOpSt ate ( ) 

222 ( 

223 if (get InternalOpSt ate ( ) ==disabled 

224 . getResourceBstate ( ) ==disabled) 

225 ( 

226 return disabled; 

227 ) 

228 else 

229 ( 

230 return enabled; 

231 ) 
232) 
233 




111 il til 



(12) 



(88) Date of publication A3: 

04.03.1998 Bulletin 1998/10 

(43) Date of publication A2: 

07.01 :i 998 Bulletin 1998/02 

(21 ) Application number: 971 1 7274.7 

(22) Date of filing : 1 8.08.1 993 



: 

Europdlschesj farm 
European Patent Office 
Office europeen des brevets (11) EP 0 81 7 422 A3 

EUROPEAN PATENT APPLICATION 

(51) Intel. 6 : H04L 12/24 



(84) Designated Contracting States: 

BE CH DE DK ES FR GB GR IE IT Lf NL 

(30) Priority: 28.08.1992 SE 9202488 
05.02.1993 SE 9300363 

(62) Document number(s) of the earlier application(s) in 
accordance with Art. 76 EPC: 
93919758.8/0 627143 

(71) Applicant: 
TELEFONAKTIEBOLAGET LM ERICSSON 
126 25 Stockholm (SE) 

(72) Inventors: 

* Carebrand, Per-Arne 
118 42 Stockholm (SE) 

* Svedberg, Johan 

115 24 Stockholm (SE) 



• Fantenberg, Johan 
112 47 Stockholm (SE) 

• Talldal, Bjdm 

161 46 Bromma (SE) 

• Palsson, Martin 
146 45 Tulfinge (SE) 

• Gilander, Anders 
195 54Mdrsta(SE) 

• Sellstedt, Patrik 

124 71 Bandhagen (SE) 

• Strdmberg Stefan 
141 52 Huddinge (SE) 

(74) Representative: 

Rosenquist, Per Olof et al 
Bergenstrahle & Lindvall AB, 
P.O. Box 17704 
118 93 Stockholm (SE) 



CO 
< 

co 
o 

CL 
UJ 



(54) A method for implementing a managed object in a network management system 



(57) The invention relates to a method for imple- 
menting a managed object in a subsystem of a man- 
aged system in a management network with at least 
one managing system and at least one managed sys- 
tem, for telecom or open systems, said managed sys- 
tem consisting of subsystems forming each a part of the 
managed system including one or more managed 
objects. 

The managed objects are implemented in the sub- 
system, uncoordinatedly with respect to other subsys- 
tems, in such a way that they can be connected to and 
transmit messages to other objects in other subsys- 
tems, and without knowing the type of objects in the 
other subsystems. This is obtained by designing a first 
object (330) for co-operation with an abstract object 
(332) defining an interface consisting of unimplemented 
methods, which may be called by the first object, and 
letting, at later design of a second object (334) unknown 
to said first object and intended to co-operate with the 
first object, the other object inherit the abstract object 
and implement the inherited methods, so that the first 
object at co-operation with the second object will con- 



sider it as being of said abstract type. 

Fig.7 
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